Stereoscopic conversion for shader based graphics content

ABSTRACT

The example techniques of this disclosure are directed to generating a stereoscopic view from an application designed to generate a mono view. For example, the techniques may modify source code of a vertex shader to cause the modified vertex shader, when executed, to generate graphics content for the images of the stereoscopic view. As another example, the techniques may modify a command that defines a viewport for the mono view to commands that define the viewports for the images of the stereoscopic view.

This application claims the benefit of U.S. Provisional Application No.61/452,289, filed Mar. 14, 2011, and U.S. Provisional Application No.61/474,638, filed Apr. 12, 2011, the contents of each is herebyincorporated by reference in its respective entirety.

TECHNICAL FIELD

This disclosure relates to graphics data processing, and moreparticularly, to graphics data processing for stereoscopic view.

BACKGROUND

Stereoscopic view refers to a perceived image that appears to encompassa 3-dimensional (3D) volume. To generate the stereoscopic view, a devicedisplays two images on a 2-dimensional (2D) area of a display. These twoimages include substantially similar content, but with slightdisplacement along the horizontal axis of one or more correspondingpixels in the two images. The simultaneous viewing of these two images,on a 2D area, causes a viewer to perceive an image that is popped out ofor pushed into the 2D display that is displaying the two images. In thisway, although the two images are displayed on the 2D area of thedisplay, the viewer perceives an image that appears to encompass the 3Dvolume.

The two images of the stereoscopic view are referred to as a left-eyeimage and a right-eye image, respectively. The left-eye image isviewable by the left eye of the viewer, and the right-eye image is notviewable by the left eye of the viewer. Similarly, the right-eye imageis viewable by the right eye of the viewer, and the left-eye image isnot viewable by the right eye of the viewer. For example, the viewer maywear specialized glasses, where the left lens of the glasses blocks theright-eye image and passes the left-eye image, and the right lens of theglasses blocks the left-eye image and passes the right-eye image.

Because the left-eye and right-eye images include substantially similarcontent with slight displacement along the horizontal axis, but are notsimultaneously viewable by both eyes of the viewer (e.g., because of thespecialized glasses), the brain of the viewer resolves the slightdisplacement between corresponding pixels by commingles the two images.The commingling causes the viewer to perceive the two images as an imagewith 3D volume.

SUMMARY

In general, the techniques of this disclosure are directed to modifyinginstructions that generate a mono view to generate a stereoscopic view.For example, a shader program of a graphics processing unit (GPU) may bedesigned to generate a mono view. The techniques described in thisdisclosure may modify the instructions of such a shader program. Forinstance, the example techniques may add instructions that modify valuesgenerated by the shader programs. The techniques may also modifyinstructions issued by an application to cause a GPU to generate imagesfor stereoscopic view instead of mono view. For example, the techniquesdescribed in this disclosure may modify commands that define a viewport.A viewport may define the size and location of the image on the display.For example, prior to modification, a command may define a viewport fora mono view. The example techniques may modify the command that define aviewport for a mono view to define a viewport for each of the images ofthe stereoscopic view.

In one example, this disclosure describes a method that includesreceiving, with a processor, instructions for a vertex shader that isconfigured to generate an image of a mono view and that is to beexecuted on a shader processor of a graphics processing unit (GPU). Themethod also includes modifying, with the processor, the instructions ofthe vertex shader to include one or more instructions that cause thevertex shader, when executed on the shader processor of the GPU, togenerate graphics content for a first image of a stereoscopic view aftera first execution of the vertex shader, and graphics content for asecond image of the stereoscopic view after a second execution of thevertex shader. The method further includes modifying, with theprocessor, a command that defines a viewport for the image of the monoview to a first command, for a fixed-function unit of the GPU that isdifferent from the shader processor, that defines a viewport for thefirst image, and a second command, for the fixed-function unit of theGPU, that defines a viewport for the second image.

In another example, this disclosure describes an apparatus that includesa graphics processing unit (GPU) that includes a shader processor and afixed-function unit, different from the shader processor, of afixed-function pipeline, and a processor. The processor is operable toreceive instructions for a vertex shader that is configured to generatean image of a mono view and that is to be executed on the shaderprocessor of GPU. The processor is also operable to modify theinstructions of the vertex shader to include one or more instructionsthat cause the vertex shader, when executed on the shader processor ofthe GPU, to generate graphics content for a first image of astereoscopic view after a first execution of the vertex shader, andgraphics content for a second image of the stereoscopic view after asecond execution of the vertex shader. The processor is further operableto modify a command that defines a viewport for the image of the monoview to a first command, for the fixed-function unit of the GPU that isdifferent from the shader processor, that defines a viewport for thefirst image, and a second command, for the fixed-function unit of theGPU, that defines a viewport for the second image.

In another example, this disclosure describes an apparatus that includesa graphics processing unit (GPU) that includes a shader processor and afixed-function unit, different from the shader processor, of afixed-function pipeline, and a processor. The processor includes meansfor receiving instructions for a vertex shader that is configured togenerate an image of a mono view and that is to be executed on theshader processor of the GPU. The processor also includes means formodifying the instructions of the vertex shader to include one or moreinstructions that cause the vertex shader, when executed on the shaderprocessor of the GPU, to generate graphics content for a first image ofa stereoscopic view after a first execution of the vertex shader, andgraphics content for a second image of the stereoscopic view after asecond execution of the vertex shader. The processor further includesmeans for modifying a command that defines a viewport for the image ofthe mono view to a first command, for a fixed-function unit of the GPUthat is different from the shader processor, that defines a viewport forthe first image, and a second command, for the fixed-function unit ofthe GPU, that defines a viewport for the second image.

In another example, this disclosure describes a non-transitorycomputer-readable storage medium comprising instructions. Theinstructions, when executed, cause one or more processors to receiveinstructions for a vertex shader that is configured to generate an imageof a mono view and that is to be executed on a shader processor of agraphics processing unit (GPU). The instructions also cause the one ormore processors to modify the instructions of the vertex shader toinclude one or more instructions that cause the vertex shader, whenexecuted on the shader processor of the GPU, to generate graphicscontent for a first image of a stereoscopic view after a first executionof the vertex shader, and graphics content for a second image of thestereoscopic view after a second execution of the vertex shader. Theinstructions also cause the one or more processors to modify a commandthat defines a viewport for the image of the mono view to a firstcommand, for a fixed-function unit of the GPU that is different from theshader processor, that defines a viewport for the first image, and asecond command, for the fixed-function unit of the GPU, that defines aviewport for the second image.

The details of one or more aspects of the disclosure are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the disclosure will be apparent from thedescription and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating an example of a device that mayimplement one or more example techniques described in this disclosure.

FIG. 2 is a block diagram illustrating an example of a graphicsprocessing unit (GPU) that may implement one or more example techniquesdescribed in this disclosure.

FIG. 3 is a block diagram illustrating the example device of FIG. 1 infurther detail.

FIG. 4 is a flowchart illustrating an example operation in accordancewith one or more example techniques described in this disclosure.

DETAILED DESCRIPTION

The example techniques described in this disclosure are directed torendering stereoscopic 3-dimensional (S3D) graphics during execution orrun time. In conventional 3D graphics rendering, a graphics processingunit (GPU) generates 3D graphics from a single point of view (e.g., monoview). This single point of view may mean a single image that isviewable by both the right eye and left eye of a viewer.

S3D graphics differs from 3D graphics in that S3D graphics generatestereoscopic view. The term stereoscopic view refers to images that aregenerated from a binocular point of view. In a binocular point of view,there may be two images, where one image is viewable by one of the eyesand not the other, and vice-versa. For example, when a viewer wearsbinoculars, the light that enters through the left lens for thebinoculars is viewable by the left eye, and not the right eye, andvice-versa. The binocular point of view may be referred to asstereoscopic view.

For example, in S3D graphics, the GPU may generate an image for theleft-eye and another image for the right-eye, i.e., a stereoscopic view.The term stereoscopic view refers to two images (e.g., left-eye imageand right-eye image) that are each displayed on the display, whereasmono view refers to a single image that is displayed on the display. Thecombination of the left-eye image and the right-eye image may appear toa viewer as if the image is popping out of or pushing into the displaythat is displaying the images. This may result in a more realistic andricher viewing experience.

In this disclosure, the concept of an S3D image (e.g., stereoscopicview) and a 3D image (e.g., mono view) should not be confused. A 3Dimage is an image that is constrained to a 2-dimensional (2D) area of adisplay. For instance, objects within a 3D image may appear further awayor closer than other objects within the 3D image. However, all of theseobjects are limited to the 2D area of the display. An S3D image is aperceived image resulting from a brain of a viewer combining theright-eye and left-eye images. The resulting image (i.e., the S3D image)appears to not be constrained to the 2D area of the display. Rather, theS3D image appears to encompass a 3D volume, where the image appears topop out of or push into the display. For instance, objects within theS3D image appear further away or closer than other objects within a 3Dvolume, and not a 2D area, as is the case with 3D images.

The right-eye and left-eye images, that together form the S3D image, maybe 3D images. It is the brain of the viewer that causes the viewer toperceive the S3D image when the brain combines the 3D right-eye imageand the 3D left-eye image. The content of the right-eye image andleft-eye images may be substantially similar to the content of thesingle 3D image. The techniques described in this disclosure may modifyinstructions that cause the GPU to generate graphics content for a monoview to instructions that cause the GPU to generate graphics content forthe stereoscopic view. In other words, prior to modification, theinstructions may cause the GPU to generate a single 3D image. Subsequentto modification, the instructions may cause the GPU to generate two 3Dimages (e.g., the 3D left-eye image and the 3D right-eye image).

It should be noted that although the techniques described in thisdisclosure are generally disclosed for 3D images, aspects of thisdisclosure are not so limited. The techniques of this disclosure may beextended to 2D graphics as well. For example, the single image of themono view may be a 2D image, and the techniques of this disclosure maymodify instructions to cause the GPU generate two 2D images for thestereoscopic view. In this case, the viewer will perceive a single imagethat is popped out of or pushed into the display that is displaying thetwo images for the stereoscopic view. To avoid confusion, the techniquesdescribed below refer to a single image for the mono view, and left-eyeand right-eye image for the stereoscopic view, with the understandingthat these images could be 3D images or 2D images.

The example techniques described in this disclosure may modifyinstructions issued by an application that are to be performed by theGPU and instructions of a vertex shader program that is to be executedby the GPU. For example, an application processor may execute theapplication. The application may have been designed to generate a singleimage (e.g., a mono view), and may generate the graphics content of thesingle image as a plurality of primitives. In addition, the applicationmay determine pixel values, such as color, transparency, and coordinatevalues, for each vertex of the primitives

During execution of the application (e.g., in run-time), the applicationissues a command to retrieve instructions of the vertex shader program.The output of the vertex shader program, when executed, may be clippingcoordinates for the vertices of primitives generated by the applicationfor the single image (e.g., mono view). The example techniques maymodify the instructions of the vertex shader program to generateclipping coordinates for the vertices of primitives for the left-eyeimage and the right-eye image (e.g., stereoscopic view).

Also, during execution of the application, the application issues a drawinstruction to the GPU to instruct the GPU to draw one or more of theprimitives within the single image. For instance, in the techniques ofthis disclosure, the application executing on the application processoroutputs instructions as if the GPU is going to generate graphics contentfor a single image. The techniques described herein modify one or moreof the instructions issued by the application, such as the drawinstruction, to generate graphics content for the left-eye and right-eyeimages. In this way, there is no modification to the instructions fromthe perspective of the application.

For instance, the techniques described in this disclosure monitor theinstructions issued by the application. When the application issues adraw instruction, the techniques capture such a draw instruction andissue two draw instructions, where one instruction is to generategraphic content for the left-eye image and one instruction is togenerate graphics content for the right-eye image.

In addition, the techniques modify the viewport instruction issued bythe application. For example, the application issues a viewportinstruction that defines the viewport of the single image. The viewportdefines the size and location of the image on the display. For example,the viewport may define the starting coordinates of the image, and thewidth and length of the image. The width and length of the image may bevalues that indicate a horizontal distance and a vertical distanceencompassed by the image. The width and length need not necessarily becoordinate values; rather, the width and length define a distancestarting from the starting coordinates of the image. The application mayprovide the definition of the viewport for the single image to the GPU.

The techniques of this disclosure modify the viewport instruction togenerate viewport instructions for the left-eye image and the right-eyeimage that define the size and the location of each of the left-eye andright-eye images on the display. In this way, the modified viewportinstruction may constrain the left-eye image to one portion of thedisplay, and the right-eye image to the other portion of the display. Insome examples, the modified viewport instruction may constrain theleft-eye image to the left half of the display, and the right-eye imageto the right half of the display. However, aspects of this disclosureare not so limited, and the modified viewport instruction may constrainthe left-eye image to the top half of the display, and the right-eyeimage to the bottom half of the display, as another non-limitingexample. In some instances, the example techniques may further modifythe viewports for the right-eye image and the left-eye image topotentially provide a better viewing experience. For example, thetechniques may shift or stretch the viewports for the right-eye imageand the left-eye image.

The instructions that modify the viewport may not be part of theinstructions that modify the shader program. For example, the GPU mayinclude a shader processor, sometime referred to as a shader core, andone or more fixed-function units. The vertex shader program may executeon the shader processor, and the application of the viewport toconstrain the image to the defined viewport may be performed by at leastone of the fixed-function units (e.g., a viewport transformation unit ofthe fixed-function units). In the example techniques, the shaderprocessor may execute the modified shader program to generate graphicscontent for the stereoscopic view, and the at least one fixed-functionunit may apply the defined viewport for each of the left-eye andright-eye images to constrain these images to respective halves of thedisplay. In other words, the viewport modification may occur external tothe execution of the modified shader program.

FIG. 1 is a block diagram illustrating an example of a device that mayimplement one or more example techniques described in this disclosure.For instance, FIG. 1 illustrates a device 10. Examples of device 10include, but are not limited to, mobile wireless telephones, personaldigital assistants (PDAs), video gaming consoles that include videodisplays, mobile video conferencing units, laptop computers, desktopcomputers, television set-top boxes, digital media players, smartphones,and the like. As illustrated in FIG. 1, device 10 may includeapplication processor 12, graphics processing unit (GPU) 20, and systemmemory 26. Device 10 may include components in addition to thoseillustrated in FIG. 1. These components are not illustrated in FIG. 1for purposes of clarity, and are further illustrated in FIG. 3.

Application processor 12 may be the central processing unit (CPU) ofdevice 10. GPU 20 may be a processing unit operable to output graphicsdata for presentation on a display. Examples of application processor 12and GPU 20 include, but are not limited to, a digital signal processor(DSP), a general purpose microprocessor, application specific integratedcircuit (ASIC), field programmable logic array (FPGA), or otherequivalent integrated or discrete logic circuitry.

System memory 26 may be an example of a computer-readable storagemedium. For example, system memory 26 may store instructions that causeapplication processor 12 and GPU 20 to perform functions ascribed toeach in this disclosure. In this way, system memory 26 may be consideredas a computer-readable storage medium comprising instructions that causeone or more processors, e.g., application processor 12 or GPU 20, toperform various functions.

Examples of system memory 26 include, but are not limited to, a randomaccess memory (RAM), a read only memory (ROM), an electrically erasableprogrammable read-only memory (EEPROM), CD-ROM or other optical diskstorage, magnetic disk storage, or other magnetic storage devices, flashmemory, or any other medium that can be used to carry or store desiredprogram code in the form of instructions or data structures and that canbe accessed by a computer or a processor. System memory 26 may, in someexamples, be considered as a non-transitory storage medium. The term“non-transitory” may indicate that the storage medium is not embodied ina carrier wave or a propagated signal. However, the term“non-transitory” should not be interpreted to mean that system memory 26is non-movable. As one example, system memory 26 may be removed fromdevice 10, and moved to another device. As another example, a storagedevice, substantially similar to system memory 26, may be inserted intodevice 10. In certain examples, a non-transitory storage medium maystore data that can, over time, change (e.g., in RAM).

GPU 20 may include shader processor 22 and fixed-function pipeline 24.Shader processor 22, sometimes referred to as a shader core, may be acore of GPU 20 upon which shader programs such as vertex shaders andfragment shaders execute. Fixed-function pipeline 24 may includehardware units that perform fixed functions. In other words, the shaderprograms such as vertex shaders and fragment shaders may be softwareunits that execute on shader processor 22 and allow for functionalflexibility, whereas fixed-function pipeline 24 include hardware unitswith fixed functions and minimal functional flexibility.

The example techniques described in this disclosure may modify shaderprograms that are designed to generate a single three-dimensional (3D)image (e.g., for a mono view), such that when the modified shaderprograms are executed on shader processor 22, GPU 20 generates graphicsdata for S3D images (e.g., a stereoscopic view). Again, as discussedabove, stereoscopic view includes a left-eye image and a right-eyeimage. The left-eye image and the right-eye image include substantiallysimilar graphics content as the mono view image; however, one or morecorresponding pixels of the left-eye and right-eye images may bedisplaced along the horizontal axis relative to one another. Forexample, imagine that the right-eye image is placed on top of theleft-eye image. In this case, all of the content in the right-eye imagemay not line up perfectly with the identical content in the left-eyeimage. Rather, one or more objects in the right-eye may be to the leftor to the right of the identical objects in the left-eye image.

The left-eye image is viewable by the left eye of the viewer, and theright-eye image is blocked from the left eye of the viewer. Theright-eye image is viewable by the right eye of the viewer, and theleft-eye image is blocked from the right eye of the viewer. In someexamples, the viewer may wear specialized glasses that block theleft-eye image from being viewable by the right eye, and the right-eyeimage from being viewable by the left eye. However, aspects of thisdisclosure do not necessarily require a viewer to wear specializedglasses. For example, some displays do not require the viewer to wearspecialized glasses to experience stereoscopic view. Techniques of thisdisclosure may be extended to such displays.

GPU 20 may generate the graphics data for the left-eye image and theright-eye image such that when the viewer views both the left-eye imageand the right-eye image at the same time the brain of the viewer causesthe viewer to perceive an image that pops out of the display or pushesinto the display displaying the two images (e.g., appears to be ahead ofor behind the display). This popping out or pushing in is due to thebrain of the viewer resolving the horizontal discrepancies in the twoimages of the stereoscopic view with substantially similar content.

As an example, application processor 12 may execute one or moreapplications, such as application 32, stored in system memory 26.Examples of application 32 include, but are not limited to, webbrowsers, user interfaces, e-mail applications, spreadsheetapplications, word processing applications, graphics authoringapplications, video games, or other applications that generate viewableobjects for display. For instance, application 32 may be a video gamethat when executed outputs graphical content that is displayed on adisplay.

Application 32 may be designed by a developer for mono view. Forexample, application 32, upon execution, may generate 3D graphicscontent, where the 3D graphics content is constrained to the 2D area ofthe display. Application 32, upon execution on application processor 12,may divide the generated 3D graphics content into primitives such astriangles, rectangles, or other types of polygons. Each of theseprimitives may include pixels that are to be displayed on the display.Application 32, upon execution on application processor 12, may alsoassign pixel values to each of the vertices of the primitives. Forexample, the pixel values may include 3D coordinates of the vertices,color values of the vertices, and transparency values of the vertices.The pixel values need not include all of the above example components inevery aspect of this disclosure.

Application processor 12 may then forward the pixel values for thevertices to GPU 20 for further processing. For example, applicationprocessor 12 may include graphics driver 14, which may be softwareexecuting on application processor 12. Graphics driver 14 may bedesigned to transmit commands to GPU 20, and in response, GPU 20 mayperform functions in accordance with the received commands. For example,graphics driver 14 functions as an interface between GPU 20 andapplication processor 12. When application processor 12 issues a commandto GPU 20, it is through graphics driver 14 that GPU 20 receives thecommand. For instance, application 32, executing on applicationprocessor 12, may instruct GPU 20 to perform a particular task. In thiscase, graphics driver 14 may receive the instruction from application 32for the particular task, and may provide the instruction to GPU 20. Inresponse, GPU 20 may perform the task.

In some examples, graphics driver 14 may be designed in accordance witha specific application programming interface (API). For example,graphics driver 14 may be designed according to the OpenGL or OpenGL ES(embedded system) APIs, which are APIs of the Khronos Group and theirspecifications are available publicly. However, the techniques of thisdisclosure may be extendable to the Microsoft DirectX system, such asDirectX 9, 10, or 11, or any other shader-based graphics system andAPIs. For purposes of illustration, the techniques of this disclosureare described in the context where the API is the OpenGL ES 2.0 API.However, aspects of this disclosure are not so limited, and can beextended to other APIs or shader-based graphics systems.

To render the primitives received from application processor 12, shaderprocessor 22 of GPU 20 may execute one or more shader programs such asvertex shaders and fragment shaders to generate the pixel values for thepixels of a display. A developer may develop these vertex shaders andfragment shaders in accordance with an API, such as the OpenGL ES 2.0API used in this disclosure for illustration purposes. The source codefor these vertex and fragment shaders may be stored in system memory 26.

For example, application 32 may utilize vertex shader 28, which may bedesigned to generate a mono view. For instance, the pixel valuesgenerated by application 32 may need to be processed by shader processor22 using vertex shader 28. As one example, vertex shader 28 may be avertex shader particularly called by application 32 during the executionof application 32 on application processor 12. Vertex shader 28 mayexecute on shader processor 22 of GPU 20, and application 32 may executeon application processor 12, but vertex shader 28 and application 32 maybe interrelated for the purposes of displaying the images generated byapplication 32.

The source code of vertex shader 28 may be stored in system memory 26.Graphics driver 14 may retrieve the source code of vertex shader 28 andprovide the source code for vertex shader 28 to compiler 18. Compiler 18may compile the source code of vertex shader 28 to generate object codeof vertex shader 28, and store the object code in system memory 28.Graphics driver 14 may then instruct GPU 20 to retrieve the object codeof vertex shader 28 from system memory 26, and instruct GPU 20 toexecute the object code of vertex shader 28 on shader processor 22.Shader processor 22 may then execute the object code of vertex shader 28to process the pixel values for the vertices generated by the executionof application 32. GPU 20, in conjunction with fixed-function pipeline24 and shader processor 22, may generate the graphics content forapplication 32 for display.

Although system memory 26 is shown to store source code for only onevertex shader 28, aspects of this disclosure are not so limited. Forexample, application 32 may possibly utilize multiple different vertexshaders, and the source code for each of these vertex shaders may bestored in system memory 26. Also, application 32 may require executionof multiple instantiations of vertex shader 28. For example, shaderprocessor 22 may execute multiple instantiations of vertex shader 28 atthe same time (e.g., in parallel), where each instantiation of vertexshader 28 performs substantially similar functions, but on differentpixel values. System memory 26 may similarly store source code forfragment shaders. Graphics driver 14 may retrieve the source code forthe fragment shaders, and compiler 18 may compile the source code togenerate object code for the fragment shaders in a manner similar tothat described above for vertex shader 28.

As will be described in further detail, one or more example techniquesof this disclosure may modify the source code of vertex shader 28 priorto the compilation. Compiler 18 may compile the modified source code togenerate object code of modified vertex shader 30. Shader processor 22may execute the object code of modified vertex shader 30, which maycause GPU 20 to generate stereoscopic 3D graphics content (e.g., thegraphics content for the left-eye image and the right-eye image of S3D).However, prior to describing the modification to the source code ofvertex shader 28, the following describes example functionality ofvertex shader 28, which may assist in the understanding of themodification applied to the source code of vertex shader 28.

As described above, application 32 may generate coordinates for thevertices of the primitives. These coordinates may be referred to asworld coordinates, and may be specific to application 32. In otherwords, the coordinates of the vertices, as defined by application 32,may not necessarily be coordinates of the display upon which theprimitives are displayed and may also possibly be coordinates forvertices that are outside of a viewable area. Vertex shader 28 may bedesigned to convert the world coordinates, which may be in 3D, into 2Dcoordinates of the display (e.g., display coordinates). To perform thisfunction, vertex shader 28 may transform the world coordinates into eyecoordinates, and then to clipping coordinates. For example, the outputof vertex shader 28, when executed, may be the clipping coordinates ofthe vertices. The final display coordinates, e.g., the coordinates ofthe display, may be determined subsequently as part of thefixed-function pipeline 24.

The clipping coordinates may define a view frustum. The view frustum maydefine the viewable area of the 3D graphics content. GPU 20 may utilizethe view frustum to cull pixels which reside external to the viewfrustum. For example, a fixed-function unit of fixed-function pipeline24 (e.g., a frustum unit of fixed-function pipeline 24) may cull pixelswhich reside external to the view frustum, as defined by the clippingcoordinates generated by vertex shader 28.

The equation to calculate the clipping coordinates from the worldcoordinates may be:

Vclip=PRJ*Veye=PRJ*MVT*Vworld,  (equation 1)

where Vclip is the vertex clip coordinates, Veye is the vertex eyecoordinates, Vworld is the vertex world coordinates provided byapplication 32, PRJ is a projection matrix, and MVT is a model viewtransformation matrix (or world view transformation matrix). In someexamples, the PRJ and MVT matrices may be combined into a single matrix.However, for ease of understanding, these matrices are describedseparately.

The projection matrix (PRJ) and model view, or world view,transformation matrix (MVT) may be defined by the API. The terms modelview and world view may be used interchangeably. Vclip, Veye, and Vworldmay include four components (e.g., x, y, z, and w coordinates). Forexample, Vclip, Veye, and Vworld may be represented as:

$\begin{matrix}{{V_{clip} = \begin{bmatrix}x_{clip} \\y_{clip} \\z_{clip} \\w_{clip}\end{bmatrix}},{V_{eye} = \begin{bmatrix}x_{eye} \\y_{eye} \\z_{eye} \\w_{eye}\end{bmatrix}},{V_{world} = \begin{bmatrix}x_{world} \\y_{world} \\z_{world} \\w_{world}\end{bmatrix}}} & \left( {{equation}\mspace{14mu} 2} \right)\end{matrix}$

The OpenGL, OpenGL ES, and OpenGL ES 2.0 APIs, with programmableshaders, define the PRJ matrix as:

$\begin{matrix}{{{PRJ} = \begin{bmatrix}\frac{2z_{near}}{\left( {R - L} \right)} & 0 & \frac{R + L}{R - L} & 0 \\0 & \frac{2z_{near}}{T - B} & \frac{T + B}{T - B} & 0 \\0 & 0 & {- \frac{z_{near} + z_{far}}{z_{far} - z_{near}}} & {- \frac{2z_{near}z_{far}}{z_{far} - z_{near}}} \\0 & 0 & {- 1} & 0\end{bmatrix}},} & \left( {{equation}\mspace{14mu} 3} \right)\end{matrix}$

where L and R specify the coordinates for the left and right verticalclipping planes, respectively, B and T specify the coordinates for thebottom and top horizontal clipping planes, respectively, and z_(near)and z_(far) specify the distances to the near and the far depth clippingplanes, respectively.

In some examples, the clipping planes may be symmetrical. For example,−L may be equal to R, and −B may be equal to T. In these instances, thePRJ matrix may simplify to:

$\begin{matrix}{{PRJ} = \begin{bmatrix}\frac{2z_{near}}{\left( {R - L} \right)} & 0 & 0 & 0 \\0 & \frac{2z_{near}}{T - B} & 0 & 0 \\0 & 0 & {- \frac{z_{near} + z_{far}}{z_{far} - z_{near}}} & {- \frac{2z_{near}z_{far}}{z_{far} - z_{near}}} \\0 & 0 & {- 1} & 0\end{bmatrix}} & \left( {{equation}\mspace{14mu} 4} \right)\end{matrix}$

The OpenGL, OpenGL ES, and OpenGL ES 2.0 APIs, with programmableshaders, define the MVT matrix as:

$\begin{matrix}{{MVT} = \begin{bmatrix}a_{11} & a_{12} & a_{13} & a_{14} \\a_{21} & a_{22} & a_{23} & a_{24} \\a_{31} & a_{32} & a_{33} & a_{34} \\0 & 0 & 0 & 1\end{bmatrix}} & \left( {{equation}\mspace{14mu} 5} \right)\end{matrix}$

All of the variables of the PRJ and MVT matrices may be defined byapplication 32 executing on application processor 12, and graphicsdriver 14 may provide these variables to shader processor 22 that isexecuting the object code of vertex shader 28. As can be seen fromequations 1, 4, and 5, with these variables, vertex shader 28 maydetermine the Vclip coordinates for each of the vertices. GPU 20 mayutilize the clip coordinates for the vertices and perform furtherfunctionality, in conjunction with the functionality of fixed-functionpipeline 26 and fragment shaders, to render an image for display. Inthis way, GPU 20 may generate a mono view for the graphics contentgenerated by application 32.

In accordance with techniques of this disclosure, while vertex shader 28may utilize the variables for the MVT and PRJ matrices to determine theVclip coordinates, the MVT and PRJ matrices may not be needed to modifythe source code of vertex shader 28 to generate the stereoscopic view.Rather, the techniques of this disclosure may include instructions invertex shader 28 that modify the clipping coordinates (Vclip), which aregenerated for a mono view, to generate clipping coordinates for thestereoscopic view (e.g., the left-eye image and the right-eye image).

The example above describes one way in which to determine the Vclipcoordinates for the mono view. There may be many different techniques tocalculate the clipping coordinates, and in general, it may be immaterialthe particular technique utilized to calculate the clipping coordinates.However, in any event, for 3D graphics content, clipping coordinates(Vclip) may need to be calculated regardless of the technique used tocalculate the clipping coordinates. For example, it may even be possiblefor application processor 12 to determine the clipping coordinates, andgraphics driver 14 may provide the clipping coordinates to shaderprocessor 22 that is executing the object code of vertex shader 28. Inthis example, the PRJ and MVT matrices may be unity matrices. Forexample, application processor 12 may perform the matrix multiplicationof equation 1 and provide the results to shader processor 22. In thisexample, shader processor 22 may multiply received values with a unitymatrix to generate the Vclip coordinates for each of the verticesgenerated by application 32.

However, in any case (e.g., where vertex shader 28 determines theclipping coordinates or where vertex shader 28 receives the clippingcoordinates), vertex shader 28 may utilize a specific variable to storethe clipping coordinates. The specific variable may be particular to theAPI for which vertex shader 28 is designed. For example, if vertexshader 28 is designed in accordance with the OpenGL, OpenGL ES, orOpenGL ES 2.0 APIs, with programmable shaders, vertex shader 28 maystore the clipping coordinates in the gl_Position variable. There may bea similar variable in other graphics APIs. For instance, if vertexshader 28 is designed in accordance with the OpenGL, OpenGL ES, orOpenGL ES 2.0 APIs, with programmable shaders, vertex shader 28 mayinclude instructions such as: gl_Position.x=x_(clip),gl_Position.y=y_(clip), gl_Position.z=z_(clip), andgl_Position.w=w_(clip), where, as indicated above in equation 2,

$V_{clip} = {\begin{bmatrix}x_{clip} \\y_{clip} \\z_{clip} \\w_{clip}\end{bmatrix}.}$

In one or more example techniques described in this disclosure, graphicsdriver wrapper 16, which may be software executing on applicationprocessor 12, may modify the instructions of vertex shader 28 thatdefine the clipping coordinates for the mono view to define clippingcoordinates for the stereoscopic view (e.g., clipping coordinates forthe left-eye image and clipping coordinates for the right-eye image).Also, graphics driver wrapper 16, in addition to modifying instructionsof vertex shader 28 that define the clipping coordinates, may modifyinstructions that define the viewport for the mono view to defineviewports for the stereoscopic view.

The term “viewport” refers to the area an image encompasses on thedisplay. For example, application 32 may define the size and location ofthe single image (e.g., mono view) on the display that displays theimage. This definition of the size and location of the single image maybe considered as the viewport for the single image. To define theviewport, application 32 may issue a glViewport command whose variablesdefine the size and location of the mono view image on the display.Graphics driver wrapper 16 may modify the command that defines the sizeand location of the single image, e.g., the glViewport command issued byapplication 32, to commands that define the size and location of theleft-eye image and the right-eye image (e.g., glViewport commands thatdefine the viewport for the left-eye image and the viewport for theright-eye image). The glViewport command for the left-eye image mayconstrain the left-eye image to one portion of the display, and theglViewport command for the right-eye image may constrain the right-eyeimage to another portion of the display.

In the examples of this disclosure, graphics driver wrapper 16 maymodify the instructions that define the viewport external to theinstructions that modify the instructions of vertex shader 28. In otherwords, graphics driver wrapper 16 may not need to modify theinstructions of vertex shader 28 to modify the viewport for the left-eyeimage and the right-eye image of the stereoscopic view. Rather, graphicsdriver wrapper 16 may modify the instruction that defines the viewportsuch that a fixed-function unit (e.g., a viewport transformation unit)of fixed-function pipeline 24 applies the viewport for the left-eyeimage that constrains the left-eye image to one portion of the display,and applies the viewport for the right-eye image that constrains theright-eye image to another portion of the display upon which theleft-eye and right-eye images are displayed.

In some examples, the viewport transformation unit of fixed-functionpipeline 24 may constrain the left-eye image to the left half of thedisplay, and the right-eye image to the right half of the display;however, aspects of this disclosure are not so limited. The viewporttransformation unit may constrain the left-eye image and the right-eyeimage to portions other than the left half and right half of thedisplay. In general, the viewport transformation unit may constrain theleft-eye image and the right-eye image to portions of the display basedon the modified viewport instruction that the viewport transformationunit receives, as described in more detail.

As one example, to cause GPU 20 to render an image, application 32 mayexecute a glShaderSource command. The glShaderSource command instructsgraphics driver 14 to retrieve the source code of vertex shader 28 fromsystem memory 26. In examples of this disclosure, in response to theglShaderSource command issued by application 32, graphics driver wrapper16 may intercept the source code of vertex shader 28 before it reachesgraphics driver 14. Graphics driver wrapper 16 may modify the sourcecode of vertex shader 28 to include instructions that cause modifiedvertex shader 28, when executed, to generate graphics content forstereoscopic view. For example, graphics driver wrapper 16 may cause themodified vertex shader 28 to execute twice. In the first execution, themodified vertex shader 28 may generate graphics content for the left-eyeimage, and in the second execution, the modified shader 28 may generategraphics content for the right-eye image, or vice-versa.

Graphics driver wrapper 16, as executed by application processor 12, mayfunction as a source code editor. As one example, graphics driverwrapper 16 may monitor the instructions issued by application 32. Whengraphics driver wrapper 16 recognizes that application 32 issued theglShaderSource command, graphics driver wrapper 16 may capture andmodify the instructions of vertex shader 28 (e.g., the source code ofvertex shader 28). For example, graphics driver wrapper 16 may includeinstructions into the instructions of vertex shader 28 that modify thevalue of the clipping coordinates generated for the single image (e.g.,mono view) to generate the clipping coordinates for the left-eye imageand the right-eye image (e.g., stereoscopic view).

For example, as indicated above, vertex shader 28 may include agl_Position.x command that stores the value for the x_(clip) coordinate.As discussed in greater detail below, graphics driver wrapper 16 mayinclude an instruction into vertex shader 28 that updates the value ofgl_Position.x (e.g., the x_(clip) coordinate). To generate the left-eyeimage, the instruction added into vertex shader 28 by graphics driverwrapper 16 causes vertex shader 28 to add a constant to the x_(clip)value. To generate the right-eye image, the instruction added intovertex shader 28 by graphics driver wrapper 16 causes vertex shader 28to subtract a constant from the x_(clip) value.

For example, graphics driver wrapper 16 may modify the source code ofvertex shader 28 to add an instruction that changes the value stored inthe gl_Position.x variable (e.g., the x_(clip) coordinate) to thecurrent value of the gl_Position.x variable plus(z_(near)*w_(world)/(R−L)/2)*X, where z_(near), R, and L are allvariables from the PRJ matrix (equation 4), and w_(world) is a variablefrom the V_(world) matrix (equation 2) (e.g., the vertex coordinates asdefined by application 32). The value of X may be +D or −D, where D isan approximation of half the distance between the right eye and the lefteye of the viewer, and may be user definable or a preprogrammed value.

As one example, graphics driver wrapper 16 may add the followinginstruction to the set of instructions of vertex shader 28:gl_Position.x+=(z_(near)*w_(world)/(R−L)/2)*X. This may be equivalent togl_Position.x=gl_Position.x+(z_(near)*w_(world)/(R−L)/2)*X. For example,the gl_Position.x+=commands adds the value defined by thegl_Position.x+=instruction to the value stored by the gl_Positioncommand (e.g., adds the value to x_(clip)). In some situations, thegl_Position.x+=instruction may simplify to gl_Position.x+=X. The reasonswhy the gl_Position.x+variable may equal (z_(near)*w_(world)/(R−L)/2)*Xor just X are described in further detail below.

In accordance with the techniques of this disclosure, to generate theleft-eye image, the graphics driver wrapper 16 may define the value ofthe variable X to be +D. When X equals +D, the gl_Position.x+=commandcauses the addition of a constant (e.g. (z_(near)*w_(world)/(R−L)/2)*Dor just D) to the x_(clip) coordinate of each of the vertices generatedby application 32 which causes the vertices to move to the left by avalue of D. To generate the right-eye image, the graphics driver wrapper16 may define the value of the variable X to be −D. When X equals −D,the gl_Position.x+=command causes the subtraction of a constant (e.g.,(z_(near)*w_(world)/(R−L)/2)*−D or just −D) from the x_(clip) coordinateof each of the vertices generated by application 32 which causes thevertices to move to the right by a value of −D.

After modifying the source code of vertex shader 28, graphics driverwrapper 16 may store the modified source code of vertex shader 28 insystem memory. In some examples, graphics driver wrapper 16 may storethe modified source of vertex shader 28 in the same location where theunmodified source code of vertex shader 28 is stored in system memory26. In alternate examples, graphics driver wrapper 16 may store themodified source of vertex shader 28 in a location in system memory 26that is different from the location where the unmodified source code ofvertex shader 28 is stored.

Subsequent to issuing the glShaderSource command, application 32 issuesa glCompileShader command. The glCompileShader command causes compiler18, executing on application processor 12, to compile the modifiedsource code of vertex shader 28. For example, the glCompileShadercommand may cause compiler 18 to retrieve the source code for themodified vertex shader 28 from system memory 26, and compile themodified vertex shader 28. After compiling, compiler 18 stores theresulting object code in system memory 26. For example, as illustrated,system memory 26 includes modified vertex shader 30. Modified vertexshader 30 is the object code resulting from compiler 18 compiling themodified source code of vertex shader 28.

Moreover, as described above, graphics driver wrapper 16 may includeinstructions in the source code of vertex shader 28 that cause vertexshader 28 to add a constant to the gl_Position.x variable to generatethe left-eye image and subtract the constant from the gl_Position.xvariable to generate the right-eye image. The object code of modifiedvertex shader 30 includes instructions that cause modified vertex shader30 to add the constant to the gl_Position.x variable to generate theleft-eye image and subtract the constant from the gl_Position.x variableto generate the right-eye image. As described in more detail, modifiedvertex shader 30 receives the value of the constant from graphics driverwrapper 16 in response to a draw command.

Application 32, upon execution by processor 12, may also issue a commandthat defines the viewport of the single image (e.g., a command thatdefines the size and location of the single image on the display). Thiscommand may be the glViewport command. The glViewport command definesthe starting coordinates for the image (e.g., x and y coordinates) andthe width and length of the image. The starting coordinates and thewidth and length values of the glViewport command define the size andlocation of the image.

In examples of this disclosure, graphics driver wrapper 16 may capturethe glViewport command issued by application 32. In some examples,graphics driver wrapper 16 may block graphics driver 14 fromtransmitting the glViewport command issued by application 32 to GPU 20.Instead, graphics driver wrapper 16 may store the starting coordinatesand the width and length values of the glViewport command, as issued byapplication 32, in system memory 26.

In an alternate example, graphics driver wrapper 16 may allow graphicsdriver 14 to transmit the glViewport command issued by application 32 toGPU 20. In this example, similar to above, graphics driver wrapper 16may store the starting coordinates and the width and length values ofthe glViewport command, as issued by application 32. In this alternateexample, prior to GPU 20 applying the glViewport command issued byapplication 32, graphics driver wrapper 16 may modify the glViewportcommand issued by application 32, and transmit the modified glViewportcommand to GPU 20. In this manner, although GPU 20 received theglViewport command issued by application 32, GPU 20 may execute themodified glViewport command, which is modified by graphics driverwrapper 16.

In either example, graphics driver wrapper 16 may then wait untilapplication 32 issues a command to GPU 20 instructing GPU 20 to draw oneor more primitives. This draw command may be a glDraw command. There arevarious examples of glDraw commands such as glDrawArrays andglDrawElements. Each of these various examples of draw commands iscommonly referred to as a glDraw command.

When application 32 issues the glDraw command, graphics driver wrapper16 captures the glDraw command, and blocks graphics driver 14 fromtransmitting the glDraw command to GPU 20. Graphics driver wrapper 16then generates instructions that cause GPU 20 to generate the graphicscontent for the left-eye image and the right-eye image. As one example,graphic driver wrapper 16 generates instructions that cause GPU 20 toexecute the object code of modified vertex shader 30 twice, issues twoglViewport commands to define the viewport for the left-eye image andthe right-eye image, and issues two glDraw commands.

As an overview of the techniques, after graphics driver wrapper 16blocks graphics driver 14 from the transmitting the glDraw commandissued by application 32, graphics driver wrapper 16 issues a command toGPU 20 that causes shader processor 22 to make the modified vertexshader 20 ready to generate clipping coordinates for a first image ofthe stereoscopic view (e.g., the left-eye image). Then, graphics driverwrapper 16 may issue a first glViewport command to a viewporttransformation unit of the fixed-function pipeline 24 which defines thesize and location of the first image on the display. Graphics driverwrapper 16 may then issue a first glDraw command to GPU 20 that causesGPU 20 to render the first image constrained to a first portion of thedisplay as defined by the first glViewport command.

Graphics driver wrapper 16 then issues a command to GPU 20 that causesshader processor 22 to make the modified vertex shader 30 ready togenerate clipping coordinates for a second image of the stereoscopicview (e.g., the right-eye image). Then, graphics driver wrapper 16 mayissue a second glViewport command to a viewport to the viewporttransformation unit of the fixed-function pipeline 24 which defines thesize and location of the second image on the display. Graphics driverwrapper 16 may then issue a second glDraw command to GPU 20 that causesGPU 20 to render the second image constrained to a second portion of thedisplay as defined by the second glViewport command.

The techniques of this disclosure, described as an overview above, aredescribed in more detail in the following examples. For ease ofunderstanding only, in the following examples, the techniques aredescribed with GPU 20 generating the graphics content for the left-eyeimage first, followed by the graphics content for the right-eye image;however, the opposite is also possible. Also, for ease of understandingonly, the techniques are described where the viewport for the left-eyeimage is constrained to the left half of the display, and the viewportfor the right-eye image is constrained to the right half of the display,although this should not be considered as limiting.

For example, after graphics driver wrapper 16 intercepts the glViewportcommand and then blocks the glDraw command issued by application 32,graphics driver wrapper 16 generates an instruction that instructs GPU20 to generate clipping coordinates for the left-eye image. Again, itshould be noted that in some examples graphics driver wrapper 16 mayblock the transmission of the glViewport command issued by application32 to GPU 20. In other examples, graphics driver wrapper 16 may allowthe glViewport command issued by application 32 to be transmitted to GPU20. However, in either of the examples, graphics driver wrapper 16 maytransmit modified glViewport commands to GPU 20. In this manner, even ifGPU 20 received the glViewport command issued by application 32, GPU 20may not execute the glViewport command issued by application 32, and mayinstead execute the modified glViewport commands issued by graphicsdriver wrapper 16. In other words, the modified glViewport commands,modified by graphics driver wrapper 16, reset the glViewport commandissued by application 32.

As one example, graphics driver wrapper 16 generates an instruction thatcauses GPU 20 to execute the object code of modified vertex shader 30.In response, shader processor 22 of GPU 20 executes the object code ofmodified vertex shader 30. In addition, graphics driver wrapper 16transmits the constant value that modified vertex shader 30 is to add tothe gl_Position.x variable to generate the clipping coordinates for theleft-eye image. The output of shader processor 22, due to the executionof the object code of modified vertex shader 30, is the clippingcoordinates for the vertices of the left-eye image.

For instance, as discussed above, graphics driver wrapper 16 may includethe following instruction into the source code of vertex shader 28:gl_Position.x+=(z_(near)*w_(world)/(R−L)/2)*X, or just gl_Position.x+=X,for reasons that will be described. The z_(near), w_(world), R, and Lvariables may possibly be known to shader processor 22, as describedabove with respect to equations (2) and (4). However aspects of thisdisclosure do not require shader processor 22 to know the values of thez_(near), w_(world), R, and L variables. For example, the z_(near),world, R, and L variables may each be constants, and therefore theresult of (z_(near)*w_(world)/(R−L)/2) would be a constant value. Inthis case, the value of (z_(near)*w_(world)/(R−L)/2) could be estimatedor user provided, and multiplied into the value of X. As described inmore detail, in some examples, (z_(near)*w_(world)/(R−L)/2) may simplifyto 1.

In some examples, shader processor 22 may not know the value of X. Forthe left-eye image, graphics driver wrapper 16 may transmit the value ofX to shader processor 22 in addition to the instruction instructingshader processor 22 to execute the object code of modified vertex shader30. In some examples, the value of X, for the left-eye image, may be +Dwhere D equals approximately half the distance between the eyes of theviewer, and may be user defined or preprogrammed. Because the value ofvariable X is +D, the gl_Position.x+=command causes shader processor 22to add the value of D to the value stored in the gl_Position.x variable(e.g., add D to the value of x_(clip)).

Graphics driver wrapper 16 also defines the viewport for the left-eyeimage. For example, prior to when application 32 issued the glDrawcommand, application 32 issued the glViewport command that graphicsdriver wrapper 16 intercepted. Graphics driver wrapper 16 also storedthe starting coordinates and the width and length values in systemmemory 32. To define the viewport for the left-eye image, graphicsdriver wrapper 16 may modify the intercepted glViewport command issuedby application 32.

For example, the glViewport command includes four variables, where thefirst two variables define the starting coordinate for the image on thedisplay, and the last two variables define the width and length of theimage. The width and length variables are not necessarily coordinatevalues. Rather, the width and length variables define the amount bywhich the image extends from the starting coordinates. For instance,application 32 may issue a glViewport command that states: glViewport(0, 0, width, length). In this example, the (0, 0) refer to thebottom-left of the display. The variable “width” refers to the width ofthe display, and the variable “length” refers to the length of thedisplay. Accordingly, in this example, application 32 defines theviewport of the image to encompass the entirety of the display, whichwould be consistent with a mono view image. However, application 32 mayassign different variables for the glViewport command, other than thoseillustrated.

In accordance with this disclosure, graphics driver wrapper 16 mayintercept the glViewport command (e.g., glViewport (0, 0, width, length)of the previous example), and modify the variables for this viewportcommand. For example, graphics driver wrapper 16 may modify thevariables of the glViewport command to constrain the left-eye image to adesired portion of the display. For ease of description, the techniquesdescribe constraining the left-eye image to the left half of thedisplay, and right-eye image to the right half of the display; however,aspects are not so limited.

For the left-eye image, graphics driver wrapper 16 may modify glViewportcommand issued by application 32 to glViewport (0, 0, width/2, length).In this example, the width/2 would be half of the width of the display.For example, the modified glViewport command indicates that the left-eyeimage with start from the left end of the display (e.g., starting from 0point on the x-axis) and extend rightwards a distance of “width/2,”which would constrain the left-eye image to the left half of thedisplay. Also, the modified glViewport command indicates that theleft-eye image will start from the bottom of the display (e.g., startingfrom the 0 point on the y-axis) and extend upwards a distance of“length,” which would constrain the image to the top and bottom of thedisplay.

Graphics driver wrapper 16 may then issue a first glDraw command to GPU20. In response to the glDraw command, GPU 20 may process the clippingcoordinates for the left-eye image generated by the execution of theobject code of the modified vertex shader 30 through fixed-functionpipeline 24 and fragment shaders. In this example, the first glViewportcommand may constrain the left-eye image to the left half of thedisplay. The glDraw command may then cause GPU 20 to render the left-eyeimage to a frame buffer for temporary storage. For example, the framebuffer may store the left-eye image until the right-eye image isgenerated. Then, GPU 20 may output the entirety of the frame buffer to adisplay processor (not shown). The display processor may cause thedisplay to display the left-eye image and the right-eye image togenerate the stereoscopic view.

Graphics driver wrapper 16 may repeat the same steps for generating theleft-eye image, but for generating the right-eye image. For example,graphics driver wrapper 16 issues another instruction to cause shaderprocessor 22 to execute the object code of modified vertex shader 30. Inaddition, graphics driver wrapper 16 transmits the constant value thatmodified vertex shader 30 is to subtract from the gl_Position.x variableto generate the clipping coordinates for the right-eye image. The outputof shader processor 22, due to the execution of the object code ofmodified vertex shader 30, is the clipping coordinates for the verticesof the right-eye image.

As described above, graphics driver wrapper 16 may add the instructiongl_Position.x+=(z_(near)*w_(world)/(R−L)/2)*X, or just gl_Position.x+=Xto the source code of vertex shader 28. For the left-eye image, thevalue of variable X may be +D (e.g., half the distance between the eyesof the viewer). In examples of this disclosure, for the right-eye image,the value of variable X may be −D. Because the value of variable X is−D, the gl_Position.x+=command causes shader processor 22 to subtractthe value of D from the value stored in the gl_Position.x variable(e.g., subtract −D from the value of x_(clip)).

Graphics driver wrapper 16 also defines the viewport for the right-eyeimage. As discussed above, for the left-eye image, graphics driverwrapper 16 defines the viewport to be glViewport (0, 0, width/2, length)to constrain the left-eye image to the left half of the display. For theright-eye image, graphics driver wrapper 16 may define the viewport tobe glViewport (width/2, 0, width/2, length). In this example, the(width/2, 0) coordinate indicates that the right-eye image will startfrom the middle of the display and extend rightwards. Also, the(width/2, length) variables in the glViewport command indicate that theright-eye image will extend half the width of the display and the fulllength of the display.

Therefore, in this example, the modified glViewport command (e.g.,glViewport (width/2, 0, width/2, length)) would constrain the right-eyeimage to the right half of the display. For example, the modifiedglViewport command indicates that the right-eye image will start fromthe middle of the display (e.g., starting from the width/2 point on thex-axis) and extend rightward a distance of “width/2,” which wouldconstrain the right-eye image to the right half of the display. Also,the modified glViewport command indicates that the right-eye image willstart from the bottom of the display (e.g., starting from the 0 point onthe y-axis) and extend upward a distance of “length,” which wouldconstrain the image to the top and bottom of the display.

Graphics driver wrapper 16 may then issue a second glDraw command to GPU20. In response to the glDraw command, GPU 20 may process the clippingcoordinates for the right-eye image generated by the execution of theobject code of the modified vertex shader 30 through fixed-functionpipeline 24 and fragment shaders. In this example, the second glViewportcommand may constrain the right-eye image to the right half of thedisplay. The glDraw command may then cause GPU 20 to render theright-eye image to the frame buffer for temporary storage. In this case,GPU 20 may have already stored the left-eye image to the frame buffer,and GPU 20 may instruct the display processor to retrieve and displaythe stored left-eye image and right-eye image from the frame buffer togenerate the stereoscopic view.

As described above, graphics driver wrapper 16 may add the instructiongl_Position.x+=command to the source code of vertex shader 28. It is thegl_Position.x+=command that is added to the source code of vertex shader28 that causes the slight displacement between the left-eye image andthe right-eye image to cause the popping out or pushing effect of thestereoscopic view. It is the modification of the instruction thatdefines the viewport for the mono view (e.g., glViewport) toinstructions that define the viewport for the right-eye and left-eyeimages that constrain the left-eye image and the right-eye image toappropriate portions of the display (e.g., the left half and right halfof the display, respectively).

To further assist with understanding, assume that graphics driverwrapper 16 did not modify the instructions of vertex shader 28 toinclude the gl_Position.x+=command, but graphics driver wrapper 16modified the glViewport command, and caused GPU 20 to execute twoglViewport commands and two glDraw commands. In this case, GPU 20 wouldrender two images because of the two glDraw commands. However, in thisexample to assist with understanding, if these two images were placed ontop of one another, there would be no displacement, and the content ofthe two images would line up perfectly. Because there is no displacementin the content of the two images, there may not be any stereoscopiceffect, and the image would appear to the viewer as a single imageconstrained to the 2D area of the display. The inclusion of thegl_Position.x+=command may cause the displacement in the content of thetwo images. Then, when the viewer simultaneously views the left-eye andright-eye images, where the left-eye image is blocked from the righteye, and the right-eye image is blocked from the left eye, the brain ofthe viewer resolves the displacement in the content of the two images tocreate the popping out or pushing in affect of the stereoscopic view.

Furthermore, in some examples, graphics driver wrapper 16 may furthermodify the viewport, in addition to the modification described above.For example, as described above, graphics driver wrapper 16 may modifythe glViewport instruction for the left-eye image to glViewport (0, 0,width/2, length), and modify the glViewport instruction for theright-eye image to glViewport (width/2, 0, width/2, length). When theviewer views these two images (e.g., the stereoscopic view), the viewermay perceive the stereoscopic image that encompasses a 3D volume on azero disparity plane (ZDP).

The ZDP may appear popped out of or pushed into the display (e.g.,appear ahead of or behind the display). However, the location of the ZDPmay not necessarily be at the desired location. For example, the viewermay experience a richer and more realistic viewing experience if the ZDPwere popped out further, not popped out as much, not pushed in as much,or pushed in further.

To change the ZDP, which may be referred to as viewport shift orshifting of the ZDP, graphics wrapper driver 16 may shift the leftboundary for the left-eye image and the right-eye image. For example,for the left-eye image, graphics wrapper 16 may modify the glViewportcommand to (0−Vps, 0, width/2, length), and for the right-eye image,graphics wrapper 16 may modify the glViewport command to ((width/2+Vps),0, width/2, length) to change the amount by which the stereoscopic viewis popped out of the display.

In these examples, the Vps value refers to viewport shift and indicatesthe amount by which the viewport of the left-eye image shifts and theamount by which the viewport of the right-eye image shifts. The Vpsvalue may be user selectable or preprogrammed. For example, if theviewer desires to shift the ZDP from its current location (e.g., priorthe viewport shift), the viewer may select the Vps value that achievesthe desired location of the ZDP. Alternatively, the Vps value may bepreprogrammed based on tests that provide a measure of where viewersconsidered the ZDP to be optimally located. For instance, if Vps is apositive value, the amount by which the stereoscopic view is popped outmay be reduced (e.g., the ZDP plane is closer to the display). If Vps isa negative value, the amount by which the stereoscopic view is poppedout may be increased (e.g., the ZDP plane is further from the display).

In some examples, in addition to a viewport shift, graphics driverwrapper 16 may modify the glViewport commands for the left-eye andright-eye images for viewport stretch. Viewport stretch may beconsidered as stretching the size of viewport, which may result in thestretching of the left-eye image and the right-eye image. In someinstances, the viewport shift and the viewport stretch may result in abetter stereoscopic view. The viewport shift and the viewport stretchmay be referred commonly as modifying the viewport. In other words,graphics driver wrapper 16 may modify the glViewport command issued byapplication 32 to generate glViewport commands for the left-eye imageand the right-eye image that define the viewports for the left-eye imageand the right-eye image, respectively. In this example, graphics driverwrapper 16 may further modify the viewports of the left-eye image andthe right-eye image (e.g., viewport shift or viewport shift and viewportstretch).

For stretching the viewport for the left-eye image, graphics driverwrapper 16 may modify the glViewport command for the left-eye image tobe glViewport (0−Vps, 0, width/2+Vps, length). For stretching theviewport for the right-eye image, graphics driver wrapper 16 may modifythe glViewport command for the right-eye image to be glViewport(width/2, 0, width/2+Vps, length). In the example techniques, theviewport shift and the viewport stretch may be not necessary in everyinstance. For instance, in some examples, graphics driver wrapper 16 maymodify the glViewport command issued by application 32 to glViewportcommands for the left-eye image and the right-eye image, and may notperform any additional viewport shifting or stretching. In somealternate examples, graphics driver wrapper 16 may modify the glViewportcommand issued by application 32, and further modify the viewports ofthe left-eye image and right-eye image (e.g., viewport shift or viewportshift and viewport stretch).

In some examples, the viewport shift and viewport stretch may beperformed at the same time as the modification of the glViewportcommand. For example, as described above, graphics driver wrapper 16 maymodify the glViewport command for the left-eye image to glViewport (0,0, width/2, length), and for the right-eye image to glViewport (width/2,0, width/2, length). In some examples, where the user desires to inputthe viewport shift value (e.g., Vps), graphics driver wrapper 16 mayshift or shift and stretch the viewport, as described above. Inalternate examples, graphics driver wrapper 16 may proactively add orsubtract the Vps values, when modifying the glViewport command, inexamples where the Vps value is preprogrammed.

As an example, assume the size of the display is 10×10 pixels, and theVps value is selected or preprogrammed to be 2 to reduce the amount bywhich the stereoscopic view is popped out. In this example, prior to theviewport shift, the viewport for the left-eye image may be (0, 0, 5, 9),and the viewport for the right-eye image may be (5, 0, 5, 9). Graphicsdriver wrapper 16 may shift the viewport for the left-eye image bysubtracting 2 (e.g., the value of Vps) to shift the ZDP. In thisexample, the viewport for the left-eye image may become (−2, 0, 5, 9).Graphics driver wrapper 16 may shift the viewport for the right-eyeimage by adding 2 (e.g., the value of Vps) to shift the ZDP. In thisexample, the viewport for the right-eye image may become (7, 0, 5, 9).Similar calculations may be performed to determine the viewport afterviewport stretch.

For the viewport shifted left-eye image, GPU 20 may crop some of thepixels of the left-eye image. For example, the coordinates of thedisplay may be (0, 0, 9, 9) in this example. However, the coordinatesfor the viewport shifted left-eye image may be (−2, 0, 5, 9), whichmeans that the viewport shifted left-eye image starts further left thanthe left edge of the display. Fixed-function pipeline 24 of GPU 20 maycrop the pixels whose coordinates are further left than the left edge ofthe display. Similarly, for the viewport shifted right-eye image, GPU 20may crop some of the pixels of the right-eye image. For example, thecoordinates for the viewport shifted right-eye image may be (7, 0, 5,9), which means that the viewport shifted right-eye image ends furtherright than the right edge of the display. Fixed-function pipeline 24 ofGPU 20 may crop the pixels whose coordinates are further right than theright edge of the display. Again, similar calculations may be performedfor viewport stretching.

The location of the viewport shifted or shifted and stretched ZDP (e.g.,the resulting ZDP from the viewport shifted or shifted and stretchedleft-eye image and right-eye image) may be determined by the followingequation:

ZDP′=z _(near)*ZDP*D/(z _(near) *D−ZDP*Vps),  (equation 6)

where ZDP′ equals the location of the viewport shifted ZDP, z_(near), isdefined in the PRJ matrix (equation 4), D is the half distance betweenthe left eye and right eye of the viewer, ZDP is the original location(e.g., prior to viewport shifting), and Vps is the amount by which theleft boundary of the left-eye image and right-eye image are shifted.

In some instances, the value of z_(near), ZDP, D, or Vps may not beavailable to the viewer. In these instances, the viewer may still modifythe Vps value (e.g., increment the value or decrement the value) untilthe viewer finds a desirable viewport shifted ZDP or shifted andstretched ZDP. The modification of the Vps value may not be necessary inevery example, and a preprogrammed Vps value may provide a suitably richand realistic viewing experience for most viewers.

In some examples, the techniques described in this disclosure may modifythe instructions to generate an image for a mono view to generate imagesfor stereoscopic view during execution or run time. For example, aviewer may select application 32 for execution, which may require theexecution of vertex shader 28 for processing the graphics generated bythe execution of application 32. While application 32 is executing orrunning on device 10, graphics driver 14, graphics driver wrapper 16,and compiler 18 may perform their respective functions to modify thesource code of vertex shader 28 and generate the object code formodified vertex shader 30. For example, graphics driver wrapper 16 mayintercept the glViewport command issued by application 32 during runtime, and block the transmission of the glViewport command issued byapplication 32 to GPU 20 during run time, in some examples, or allow thetransmission of the glViewport command issued by application 32 to GPU20 in other examples. In either example, graphics driver wrapper 16 maymodify the glViewport command issued by application 32 so that theglViewport command executed by GPU 20 is the modified glViewport commandmodified by graphics driver wrapper 16.

Moreover, when application 32 issues the draw command (e.g., glDraw),graphics driver wrapper 16 may capture and block this glDraw fromtransmission to GPU 20. This glDraw command, which application 32 issuedduring run time, may function as the trigger that causes graphics driverwrapper 16 to include instructions that define the viewport for theleft-eye image and the right-eye image, in a manner described above, andinclude two glDraw commands to cause GPU 20 to generate graphics contentfor the left-eye image and the right-eye image.

Also, although the above examples are described in the context where thegraphics driver wrapper 16 adds instructions to and modifies theinstructions of vertex shader 28 and modifies the instruction thatdefines the viewport, aspects of this disclosure are not so limited. Inalternate examples, rather than graphics driver wrapper 16, it may bepossible for graphics driver 14 or compiler 18 to modify theinstructions of vertex shader 28 and the instruction that defines theviewport. However, these examples may require modification to graphicsdriver 14 or compiler 18.

Modification to graphics driver 14 or compiler 18 may be more difficultthan developing graphics driver wrapper 16 and having graphics driverwrapper 16 perform the functions described in this disclosure so thatGPU 20 generates the left-eye image and the right-eye image for thestereoscopic view. For example, device 10 may have been loaded withpreexisting graphics driver 14 and compiler 18, and it may be difficultto change graphics driver 14 and compiler 18. By adding graphics driverwrapper 16 that performs the modification to vertex shader 28, theexample techniques may not require modification to preexisting graphicsdriver 14 and compiler 18.

Furthermore, the techniques described above may allow GPU 20 to generateimages for the stereoscopic view without modification to application 32.For example, some other techniques to generate stereoscopic view mayrequire the developers of application 32 to modify the source code ofapplication 32 to generate pixel values for the left-eye and right-eyeimages. These techniques required assistance from the developer ofapplication 32 to modify their applications for stereoscopic view, whichmay be potentially cumbersome task for the developer of application 32.The example techniques described above may provide stereoscopic view forapplication 32, developed for mono view, without any assistance from thedeveloper of application 32.

Also, the techniques described above may not require multiple calls tosystem memory 26 for generating the left-eye and right-eye images forstereoscopic view. For example, in some other techniques to generatestereoscopic view, a GPU would generate the left-eye image. Uponcompletion of the generation of the left-eye image, the GPU wouldutilize depth information stored in system memory 26 while generatingthe left-eye image to generate the right-eye image. However, repeatedcalls to system memory 26 to retrieve the depth information may becomputationally expensive and may require excessive power consumption.

The example techniques described above may not require such multiplecalls to system memory 26 for the depth information for the left-eyeimage to generate the right-eye image. For example, graphics driverwrapper 16 may modify the source code of vertex shader 28 and theinstruction that defines the viewport to generate the left-eye andright-eye images independently from one another, without necessarilyneeding the depth information of one image to generate the other image.For instance, the instructions that are added into vertex shader 28 andthe modification of the glViewport commands and the issuances of twoglDraw commands, as described above, may not require any depthinformation, and in some examples, generate the left-eye image withoutrequiring information about right-eye image, and vice-versa. In thisway, the techniques described in this disclosure may reduce the numberof access to system memory 26 for generating the stereoscopic view, ascompared to other techniques.

Moreover, as described above, the glViewport command is utilized by afixed-function unit of fixed-function pipeline 24 (e.g., the viewporttransformation unit of fixed-function pipeline 24), and not by shaderprocessor 22. In this way, the source code for vertex shader 28 may notneed to be modified to force rendering of the left-eye image to a firstportion of the display (e.g., the left-half of the display), and forcerendering of the right-eye image to the other portion of the display(e.g., the right-half of the display). Rather, a fixed-function unit offixed-function pipeline 24 may apply the modified glViewport commands toconstrain the left-eye image to its portion of the display and theright-eye image to its portion of the display. This may reduce andsimplify the modifications to vertex shader 28, which may increase thecomputational efficiency of shader processor 22.

For example, in accordance with the techniques of the disclosure,graphics driver wrapper 16 may modify the source code of vertex shader28 to provide the displacement between the left-eye image and theright-eye image. For instance, when generating the clipping vertexcoordinates for the left-eye image and the right-eye image, shaderprocessor 22, which is executing the object code of modified vertexshader 30, may be oblivious to where the generated graphics data will bedisplayed. In other words, shader processor 22 may not be tasked withdefining where the graphics data is to be presented for the left-eyeimage and the right-eye image. The viewport transformation unit offixed-function pipeline 24, which is a unit external to shader processor22, may be tasked with constraining the left-eye and right-eye images totheir respective portions of the display. In this way, shader processor22 may not need to waste computational cycles in determining where theleft-eye and right-eye images should be displayed. The hardwiredfunctionality of the viewport transform unit of fixed-function pipeline24 may be more suitable for constraining the left-eye image theright-eye image to their respective portions on the display, as comparedto shader processor 22.

For example, if the source code for vertex shader 28 were modified todetermine where the left-eye and right-eye images should be displayed soas to control the zero disparity plane (ZDP), it may require shaderprocessor 22 to determine the coordinates for each vertex of each of theprimitives in the left-eye and right-eye images. This may require shaderprocessor 22 to perform multiple computational cycles which may reducethe efficiency of shader processor 22. By performing the viewporttransformation, and also the viewport shift or shift and stretch (e.g.,further modifying the viewport based on the Vps value to adjust theZDP), in the viewport transformation unit of fixed-function pipeline 24,aspects of this disclosure may provide richer stereoscopic view withoutwasted computation cycles in the shader processor 22.

As described above, graphics driver wrapper 16 may include thegl_Position.x+=(z_(near)*w_(world)/(R−L)/2)*X or just gl_Position.x+=Xcommand into the source code of vertex shader 28 that modifies the valueof the gl_Position.x variable. The following provides the reasons forsuch an inclusion of instructions into the source code of vertex shader28.

As indicated above in equation (1), Vclip=PRJ*Veye=PRJ*MVT*Vworld. Theequation for Vclip may be modified to generate clipping coordinates forthe left-eye and the right-eye. For example, the clipping coordinatesfor the left-eye and right-eye may be:

Vclip_left-eye=PRJ*VTleft-eye*Veye=PRJ*VTleft-eye*MVT*Vworld  (equation7), and

Vclip_right-eye=PRJ*VTright-eye*Veye=PRJ*VTright-eye*MVT*Vworld  (equation8).

VTleft-eye and VTright-eye may be 4×4 matrices that are based on anassumed distance of the left eye and right eye away from the mono view.The coordinates of the mono view may be (0, 0, 0), and the left eye maybe considered as being located at (−D, 0, 0), and the right eye may beconsidered as being located at (D, 0, 0). In other words, the (0, 0, 0)location may be considered as being in the middle of the right eye andthe left eye of the viewer. If the left eye is considered to be located−D away from the middle of the right eye and the left eye, and right eyeis considered to be located +D away from the middle of the right eye andthe left eye, then D indicates half of the distance between the righteye and left eye of the viewer.

The matrices for VTleft-eye and VTright-eye may be defined as:

${VT}_{{left}\; \_ \; {eye}} = {{\begin{bmatrix}1 & 0 & 0 & D \\0 & 1 & 0 & 0 \\0 & 0 & 0 & 1 \\0 & 0 & 0 & 1\end{bmatrix}\mspace{14mu} {and}\mspace{14mu} {VT}_{{right}\; \_ \; {eye}}} = \begin{bmatrix}1 & 0 & 0 & {- D} \\0 & 1 & 0 & 0 \\0 & 0 & 1 & 0 \\0 & 0 & 0 & 1\end{bmatrix}}$

VTleft-eye and VTright-eye may be rewritten as a sum of two matrices.For example, VTleft-eye may be rewritten as

${VT}_{{left}\; \_ \; {eye}} = {\begin{bmatrix}1 & 0 & 0 & 0 \\0 & 1 & 0 & 0 \\0 & 0 & 1 & 0 \\0 & 0 & 0 & 1\end{bmatrix} + {\begin{bmatrix}0 & 0 & 0 & D \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0\end{bmatrix}.}}$

VTright-eye may be rewritten as

${VT}_{{right}\; \_ \; {eye}} = {\begin{bmatrix}1 & 0 & 0 & 0 \\0 & 1 & 0 & 0 \\0 & 0 & 1 & 0 \\0 & 0 & 0 & 1\end{bmatrix} + {\begin{bmatrix}0 & 0 & 0 & {- D} \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0\end{bmatrix}.}}$

By substituting the VTleft-eye matrix into the equation forVclip_left-eye (equation 7), Vclip_left-eye equals:

$\begin{matrix}{{{Vclip\_ left}\text{-}{eye}} = {{P\; R\; J*\begin{bmatrix}1 & 0 & 0 & 0 \\0 & 1 & 0 & 0 \\0 & 0 & 1 & 0 \\0 & 0 & 0 & 1\end{bmatrix}*M\; V\; T*{Vworld}} + {P\; R\; J*\begin{bmatrix}0 & 0 & 0 & D \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0\end{bmatrix}*M\; V\; T*{{Vworld}.}}}} & \left( {{equation}\mspace{14mu} 9} \right)\end{matrix}$

By substituting the VTright-eye matrix into the equation forVclip_right-eye (equation 8), Vclip_right-eye equals:

$\begin{matrix}{{{VTclip\_ right}\text{-}{eye}} = {{P\; R\; J*\begin{bmatrix}1 & 0 & 0 & 0 \\0 & 1 & 0 & 0 \\0 & 0 & 1 & 0 \\0 & 0 & 0 & 1\end{bmatrix}*M\; V\; T*{Vworld}} + {P\; R\; J*\begin{bmatrix}0 & 0 & 0 & {- D} \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0\end{bmatrix}*M\; V\; T*{{Vworld}.}}}} & \left( {{equation}\mspace{14mu} 10} \right)\end{matrix}$

In both equations 9 and 10, e.g., for Vclip_left-eye andVclip_right-eye,

$P\; R\; {J^{*}\begin{bmatrix}1 & 0 & 0 & 0 \\0 & 1 & 0 & 0 \\0 & 0 & 1 & 0 \\0 & 0 & 0 & 1\end{bmatrix}}*M\; V\; T*{Vworld}$

can be simplified to PRJ*MVT*Vworld because

$\quad\begin{bmatrix}1 & 0 & 0 & 0 \\0 & 1 & 0 & 0 \\0 & 0 & 1 & 0 \\0 & 0 & 0 & 1\end{bmatrix}$

is a unity matrix and is equivalent to multiplying by one.

As described above in equation 1, PRJ*MVT*Vworld equals Vclip.Therefore, the Vclip_left-eye and Vclip_right-eye equations (e.g.,equations 9 and 10, respectively) can be rewritten as:

$\begin{matrix}{{{{Vclip\_ left}\text{-}{eye}} = {{Vclip} + {{PRJ}*\begin{bmatrix}0 & 0 & 0 & D \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0\end{bmatrix}*M\; V\; T*{Vworld}}}},\mspace{79mu} {and}} & \left( {{equation}\mspace{14mu} 11} \right) \\{{{Vclip\_ left}\text{-}{eye}} = {{Vclip} + {{PRJ}*\begin{bmatrix}0 & 0 & 0 & {- D} \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0 \\0 & 0 & 0 & 0\end{bmatrix}*M\; V\; T*{{Vworld}.}}}} & \left( {{equation}\mspace{14mu} 12} \right)\end{matrix}$

By substituting the matrices for the PRJ and MVT (equations 4 and 5,respectively), and performing the matrix multiplication of equation 11,the equation for Vclip_left-eye may simplify to:

${{{Vclip\_ left}\text{-}{eye}} = {{Vclip} + {\frac{z_{near}}{\left( {R - L} \right)/2}*D*w_{world}*\begin{bmatrix}1 \\0 \\0 \\0\end{bmatrix}}}},$

and more specifically to:

$\begin{matrix}\begin{matrix}{V_{{{clip\_ lef}t}\text{-}{eye}} = \begin{bmatrix}x_{{left\_ eye}{\_ clip}} \\y_{{left\_ eye}{\_ clip}} \\z_{{left\_ eye}{\_ clip}} \\w_{{left\_ eye}{\_ clip}}\end{bmatrix}} \\{= {\begin{bmatrix}{x_{clip} + {\frac{z_{near}}{\left( {R - L} \right)/2}*D*w_{world}}} \\y_{clip} \\z_{clip} \\w_{clip}\end{bmatrix}.}}\end{matrix} & \left( {{equation}\mspace{14mu} 13} \right)\end{matrix}$

With similar substitutions to those for Vclip_left-eye, theVclip_right-eye equation may simplify to:

${{{Vclip\_ right}\text{-}{eye}} = {{Vclip} - {\frac{z_{near}}{\left( {R - L} \right)/2}*D*w_{world}*\begin{bmatrix}1 \\0 \\0 \\0\end{bmatrix}}}},$

and more specifically to:

$\begin{matrix}\begin{matrix}{V_{{clip\_ right} - {eye}} = \begin{bmatrix}x_{{right\_ eye}{\_ clip}} \\y_{{right\_ eye}{\_ clip}} \\z_{{right\_ eye}{\_ clip}} \\w_{{right\_ eye}{\_ clip}}\end{bmatrix}} \\{= {\begin{bmatrix}{x_{clip} - {\frac{z_{near}}{\left( {R - L} \right)/2}*D*w_{world}}} \\y_{clip} \\z_{clip} \\w_{clip}\end{bmatrix}.}}\end{matrix} & \left( {{equation}\mspace{14mu} 14} \right)\end{matrix}$

From equations 13 and 14, it can be seen that by adding the constant

$\frac{z_{near}}{\left( {R - L} \right)/2}*D*w_{world}$

to the calculated x_(clip) coordinate, and keeping all other clippingcoordinates the same, vertex shader 28 may generate the clippingcoordinates for the left-eye image. Similarly, by subtracting theconstant

$\frac{z_{near}}{\left( {R - L} \right)/2}*D*w_{world}$

from the x_(clip) coordinate, and keeping all other clipping coordinatesthe same, vertex shader 28 may generate the clipping coordinates for theright-eye image. For at least these reasons, graphics driver wrapper 16may include the instructiongl_Position.x+=z_(near)*w_(world)/((R−L)/2)*X, where X equals +D togenerate the left-eye image, and where X equals −D to generate theright-eye image.

In some examples, it may be possible to further simplify thegl_Position.x+=command to just gl_Position.x+=X. For example, it iscommon for the w_(world) variable to be set to 1. Also, OpenGL, OpenGLES, and OpenGL ES 2.0, with programmable shaders, define a frustum tobe:

${\cot \left( {fov}_{x} \right)} = {\frac{z_{near}}{\left( {R - L} \right)/2}.}$

where fov_(x) is a frustum defined in OpenGL, OpenGL ES, and OpenGL ES2.0. It is also common for the viewing angle to be set to 45 degrees,which means that cot(fov_(x)) equals 1. This means that

$\frac{z_{near}}{\left( {R - L} \right)/2}\mspace{14mu} {equals}\mspace{14mu} 1.$

Therefore, in these examples,

$\frac{z_{near}*w_{world}}{\left( {R - L} \right)/2}*X$

simplifies to just X (e.g.,

$\frac{z_{near}}{\left( {R - L} \right)/2}\mspace{14mu} {equals}\mspace{14mu} 1.$

and w_(world) equals 1). In these examples, the gl_Position.x+=variablemay simplify to gl_Position.x+=X.

Accordingly, equations 7-14 provide mathematical foundation thatillustrates the reasons why adding the instructiongl_Position.x+=(z_(near)*w_(world)/(R−L)/2)*X, or gl_Position.x+=X tovertex shader 28 may be sufficient to displace the mono view image togenerate stereoscopic view, when executed twice, and where X equals +Din the first execution, and −D in the second execution. In this way, thetechniques of this disclosure may provide for a minor modification tothe source code of vertex shader 28, which is designed for mono view,such that when the modified source code is compiled and executed (e.g.,the execution of the object code of modified vertex shader 30), theresulting images may provide the viewer with a stereoscopic view. Thestereoscopic view may provide the viewer with a 3D experience, which maybe richer, fuller experience, as compared to viewing an image limited bythe 2D area of the display.

In some examples, graphics driver wrapper 16 may include the commandgl_Position.x+=X even when (z_(near)*w_(world)/(R−L)/2) does notsimplify to 1 (e.g., where cot(fov_(x)) does not equal 1 because theviewing angle is not 45 degrees and/or w_(world) does not equal 1). Forinstance, (z_(near)*w_(world)/(R−L)/2) may be constant because z_(near),w_(world), R, and L are each constants. Since(z_(near)*w_(world)/(R−L)/2) is a constant, the value of(z_(near)*w_(world)/(R−L)/2)*X is a constant because X is a constant. Inthis case, (z_(near)*w_(world)/(R−L)/2)*X may be collapsed to representa single constant, which may simply be X. In this case, the value of Xmay be user specified or preprogrammed. For instance, in the aboveexamples, X equaled +D for the left-eye image and −D for the right-eyeimage. In this current example, X may equal(z_(near)*w_(world)/(R−L)/2)*D for the left-eye image and(z_(near)*w_(world)/(R−L)/2)*−D for the right-eye image, where(z_(near)*w_(world)/(R−L)/2) and D may be user specified forpreprogrammed values, if the z_(near), w_(world), R, and L values arenot available to shader processor 22.

If the z_(near), w_(world), R, and L values are available to the shaderprocessor 22, shader processor 22 may determine the value of(z_(near)*w_(world)(R−L)/2) and multiple that value with +D or −D basedon whether GPU 20 is generating graphics content for the left-eye imageor the right-eye image. Also, again, if cot(fov_(x)) and w_(world) bothequal 1, then (z_(near)*w_(world)/(R−L)/2) may simplify to 1.

FIG. 2 is a block diagram illustrating an example of a graphicsprocessing unit (GPU) that may implement one or more example techniquesdescribed in this disclosure. For example, FIG. 2 illustrates thecomponents of GPU 20 in greater detail. As illustrated in FIG. 2, GPU 20includes command processor 54, shader processor 22, and fixed-functionpipeline 24. Command processor 54 may function as the interface betweenGPU 20 and application processor 12. For instance, command processor 54may receive commands from application processor 12, and may determinewhether the commands should be forwarded to shader processor 22 orfixed-function pipeline 24.

As one example, as described above, application processor 12, executingapplication 32, may instruct GPU 20 to execute the object code ofmodified vertex shader 30. In this example, command processor 54 mayreceive the command from application processor 12, and may instructshader processor 22 to execute the object code of modified vertex shader30. As another example, as described above, graphics driver wrapper 16may modify the glViewport command issued by application 32, and providethe modified glViewport commands to GPU 20. In this example, commandprocessor 54 may receive the modified glViewport commands, and determinethat this command is for viewport transformation unit 42 offixed-function pipeline 24. Command processor 54 may forward themodified glViewport commands to viewport transformation unit 42 forapplying the viewports for the left-eye image and right-eye image.

For example, as described above, application 32 may issue a glDrawcommand that graphics driver wrapper 16 blocks from transmission to GPU20. The glDraw command may trigger graphics driver wrapper 16 intoissuing a first instruction to shader processor 22 to execute the objectcode of modified vertex shader 30. In turn, shader processor 22 executesthe object code of modified vertex shader 30, and stores the resultingclipping coordinates in its local memory or system memory 26. The glDrawcommand also causes graphics driver wrapper 16 to issue a first modifiedglViewport instruction, which is received by command processor 54. Then,graphics driver wrapper 16 issues the first glDraw command which isreceived by command processor 54. Command processor 54, in response,causes the fixed-function units of fixed-function pipeline 24 and shaderprocessor 22 to perform their respective functions to generate thegraphics content for a first image of the stereoscopic view (e.g., theleft-eye image). For example, as discussed in more detail, in responseto the first glDraw command, viewport transformation unit 42 constrainsthe first image to a first portion of the display, and per-fragmentoperation unit 50 outputs the graphics content of the first image toframe buffer 52.

After the first image of the stereoscopic view is stored in frame buffer52, GPU 20 repeats the steps to generate the graphics content for thesecond image of the stereoscopic view. For example, graphics driverwrapper 16 issues a second instruction to shader processor 22 to executethe object code of modified vertex shader 30. In turn, shader processor22 executes the object code of modified vertex shader 30, and stores theresulting clipping coordinates in its local memory or system memory 26.Graphics driver wrapper 16 also issues a second modified glViewportinstruction, which is received by command processor 54. Then, graphicsdriver wrapper 16 issues the second glDraw command which is received bycommand processor 54. Command processor 54, in response, causes thefixed-function units of fixed-function pipeline 24 and shader processor22 to perform their respective functions to generate the graphicscontent for a second image of the stereoscopic view (e.g., the right-eyeimage). For example, in response to the second glDraw command, viewporttransformation unit 42 constrains the second image to a second portionof the display, and per-fragment operation unit 50 outputs the graphicscontent of the second image to frame buffer 52. This functionality ofGPU 20 is described in more detail in the following examples.

As illustrated in dashed boxes in FIG. 2, shader processor 22 includesmodified vertex shader 30 and fragment shader 46. The dashed boxes areto indicate that shader processor 22 may not actually include modifiedvertex shader 30 and fragment shader 46. Rather, shader processor 22 mayexecute the object code of modified vertex shader 30 and fragment shader46. The object of modified vertex shader 30 and fragment shader 46 maybe stored in system memory 26.

Fixed-function pipeline 24 may include one or more fixed-function unitssuch as primitive assembly unit 36, frustum unit 38, perspective divideunit 40, viewport transformation unit 42, rasterization unit 44, andper-fragment operation unit 50. Each of these fixed-function units offixed-function pipeline 24 may be hardware units that are hardwired toperform specific graphics related functions. Although thesefixed-function units of fixed-function pipeline 24 are illustrated asseparate components, aspects of this disclosure are not so limited. Oneor more of the fixed-function units of fixed-function pipeline 24 may becombined together into a common fixed-function unit. Also, there may bemore fixed-function units of fixed-function pipeline 24 than thoseillustrated in FIG. 2. The one or more fixed-function units offixed-function pipeline 24 are illustrated separately to easeunderstanding.

Moreover, the specific ordering of the fixed-function units offixed-function pipeline 24 is illustrated for example purposes andshould not be considered limiting. For instance, it may be possible toreorder the fixed-function units of fixed-function pipeline 24. As oneexample, one of the functions of per-fragment operation unit 50 may beto cull pixels that are occluded by overlapping pixels. It may bepossible for this function to be performed earlier in fixed-functionpipeline 24.

These fixed-function units of fixed-function pipeline 24 may providevery limited functional flexibility, as compared to shader processor 22.For example, shader processor 22 may be specifically designed to executeprogrammable shader programs such as modified vertex shader 30 andfragment shader 46. These shader programs cause shader processor 22 tofunction in the manner defined by the shader programs. In other words,shader programs may define the functionality of shader processor 22,whereas the functionality of the fixed-function units of fixed-functionpipeline 24 is set.

As described above, graphics driver wrapper 16 may instruct GPU 20 toexecute the object code of modified vertex shader 30 twice, where thefirst execution is for the generation of clipping coordinates forvertices of one of the images of stereoscopic view (e.g., left-eyeimage) and the second execution is for the generation of clippingcoordinates for vertices of the other image of stereoscopic view (e.g.,right-eye image). In response, to each of these instructions to executethe object code of modified vertex shader 30, command processor 54 mayinstruct shader processor 22 to retrieve the object code of modifiedvertex shader 30 and execute it. As described above, compiler 18 maycompile the source code of the modified vertex shader and store theresulting object code as the object code of modified vertex shader 30.As illustrated in FIG. 2, modified vertex shader 30 may receive vertexarray 34 and textures 48 as inputs. Vertex arrays 34 may includeinformation to generate the pixel values for the vertices generated byapplication 32 (e.g., the coordinates of the vertices, color values ofthe vertices, and transparency values of the vertices), as describedabove. For example, the coordinates of the vertices of vertex array 34may be the world coordinates as defined by application 32. Textures 48may be pixel values for textures that overlay over the generatedgraphics to provide a more realistic view of the graphics content.

Modified vertex shader 30, executing on shader processor 22, maygenerate the clipping coordinates for each of the vertices. For example,modified vertex shader 30 may convert the world coordinates of thevertices as defined by application 32 and stored in vertex array 34 intoclipping coordinates for each of the vertices by performing the matrixmultiplication of equation 1, as discussed above with respect to FIG. 1.Furthermore, modified vertex shader 30, executing on shader processor22, may update the gl_Position.x variable for the clipping coordinatesof each of the vertices to provide the displacement for the left-eyeimage, in the first execution of the object code of modified vertexshader 30, and to provide the displacement for the right-eye image, inthe second execution of the object code of modified vertex shader 30.Also, modified vertex shader 30 may perform additional, conventionalvertex shader tasks. For example, modified vertex shader 30 may performlighting functions on the vertices.

After modified vertex shader 30 performs the model view transformation(e.g., conversion of the world view coordinates to clipping coordinates,including the displacement with the gl_Position.x+=command), modifiedvertex shader 30 provides the clipping coordinates for the vertices toprimitive assembly unit 36 of fixed-function pipeline 24. Primitiveassembly unit 36 may utilize the clipping coordinates for the verticesto assemble the vertices into primitives. For example, primitiveassembly unit 36 may assemble a plurality of triangles based on theclipping coordinates for the vertices, where the vertices of each of thetriangles correspond to vertices received from modified vertex shader30. The plurality of triangles is one example of primitives. In general,primitive assembly unit 36 may assemble the received vertices into anypolygon based on the clipping coordinates for the received vertices.

Primitive assembly unit 36 may transmit the assembled primitives tofrustum unit 38. Frustum unit 38 may determine whether the assembledprimitives are within a view volume. For example, as described above,OpenGL, OpenGL ES, and OpenGL ES 2.0 may define a particular view volumeas (fov_(x)). However, the frustum may be user definable using, forexample, the glFrustum function. Frustum unit 38 may determine whether aprimitive is fully within the view volume, fully external to the viewvolume, or partially within the view volume and partially external tothe view volume. Frustum unit 38 may cull, from further processing,primitives that are fully external to the view volume and portions ofprimitives are that external to the view volume. Frustum unit 38 maykeep, for further processing, primitives that are fully within the viewvolume and portions of primitives that are within the view volume.

Frustum unit 38 may transmit the remaining primitives and portions ofprimitives to perspective divide unit 40. Perspective divide unit 40 mayexpand or shrink primitives based on their depth. For example, each ofthe primitives may be defined by x, y, and z coordinates. The zcoordinate may indicate how close or away the primitive is. It should benoted that at this stage, GPU 20 is generating graphics content for oneof the images for the stereoscopic view. Therefore, the concept ofproximity of a primitive is in the context of a mono view, not astereoscopic view.

For instance, perspective divide unit 40 may shrink some primitives, andexpand other primitives. This may create a perception that the shrunkprimitives are further away compared to the expanded primitives in amono view. As described above, it is when these mono view images aredisplayed that the viewer perceives stereoscopic view. In other words,perspective divide unit 40 may cause the left-eye image and theright-eye image to be 3D images that are displayed in the 2D area of thedisplay. When the viewer views these 3D images, the displacement causedby the addition of the gl_Position.x+=command, in the left-eye image andthe right-eye image, causes the viewer to perceive the stereoscopic 3D(S3D) image that encompasses a 3D volume.

Perspective divide unit 40 may transmit the primitives to viewporttransformation unit 42. Viewport transformation unit 42 modifies thesize and location of the image to fit the defined viewport. For example,prior to the viewport transformation unit 42, modified vertex shader 30and the fixed-function units of fixed-function pipeline 24 processgraphics data as if the image is to be displayed on the entirety of thedisplay. The function of viewport transformation unit 42 may be tomodify the size and location of the image so that the image isconstrained to the defined viewport.

For instance, as described above, after the first execution of theobject code of vertex shader 30, which may generate graphics content forthe left-eye image (e.g., clipping coordinates for vertices), graphicsdriver wrapper 16 may modify the viewport of the left-eye image toconstrain the left-eye image to the left-half of the display. Forexample, after the first execution of the object code of vertex shader30, graphics driver wrapper 16 may modify the glViewport (0, 0, width,length) command, which was previously issued by application 32 andblocked from GPU 20, to glViewport (0, 0, width/2, length), and providethis first modified glViewport command to GPU 20. Command processor 54may provide the first modified glViewport command to viewporttransformation unit 42. Viewport transformation unit 42 may then modifythe sizes of the primitives received from perspective divide unit 40 sothat these primitives are constrained to the left-half of the display,in this example. For instance, perspective divide unit 40 may modify thesizes of the primitives relative to one another so that some primitivesappear closer than other primitives. Viewport transformation unit 42 mayproportionally modify the size and location of the primitives such thatthe primitives are constrained to the left-half of the display.

After the second execution of the object code of vertex shader 30,viewport transformation unit 42 may perform similar functions, but forthe right-eye image. For example, the second execution of the objectcode of vertex shader 30 may be for the generation of graphics contentfor the right-eye image (e.g., clipping coordinates for vertices). Afterthis second execution of the object code of vertex shader 30, graphicsdriver wrapper 16 may modify the glViewport (0, 0, width, length)command, which was previously issued by application 32 and blocked fromGPU 20, to glViewport (width/2, 0, width/2, length), and provide thissecond modified glViewport command to GPU 20. Command processor 54 mayforward the second modified glViewport command to viewporttransformation unit 42. Viewport transformation unit 42 mayproportionally modify the size and location of the primitives such thatthe primitives are constrained to the right-half of the display. In thisway, GPU 20 may be operable to generate left-eye and right-eye imagesfor the stereoscopic view from a mono view image generated byapplication 32 during run-time of application 32, and without relying ondepth information to generate the right-eye image from the left-eyeimage, and vice versa.

Furthermore, viewport transformation unit 42 may perform the viewportshift or viewport shift and stretch, as described above. For example, asdescribed above, the viewer may provide a Vps value, or the Vps valuemay be preprogrammed, where the Vps value indicates the amount by whichthe viewport for the left-eye image and the right-eye image shouldshifted or shifted and stretched. In this example, viewporttransformation unit 42 may be operable to perform the viewport shiftingand stretching as well. The viewport shifting or shifting and stretchingmay cause the perceived stereoscopic view to pop out further from thedisplay, not pop out as much from the display, not push into thedisplay, or push further into the display.

For viewport shifting or shifting and stretching, command processor 54may retrieve the user provided or preprogrammed Vps value, and providethe Vps value to viewport transformation unit 42. In this example,viewport transformation unit 42 may receive the modified glViewportcommand for the left-eye image as glViewport (0−Vps, 0, width/2, length)or glViewport (0−Vps, 0, width/2+Vps, length) and for the right-eyeimage as glViewport (width/2+Vps, 0, width/2, length) or glViewport(width/2, 0, width/2+Vps, length). Viewport transformation unit 42 mayperform the viewport shifting of shifting and stretching for theleft-eye image and the right-eye image, and perform any culling if theviewport extends outside of the display area of the display. Asdescribed above, the viewport shifting or shifting and stretching mayprovide the viewer with a richer stereoscopic view.

Viewport transformation unit 42 may forward the primitives torasterization unit 44 after modifying the viewport after each of thefirst modified glViewport command and the second modified glViewportcommand. Rasterization unit 44 may convert the primitives into pixels ofthe display. For example, rasterization unit 44 may determine whichpixels of the display are encompassed by each of the primitives.Rasterization unit 44 may also determine the location of each of thesepixels on the displays.

Rasterization unit 44 may output its graphics data to fragment shader46. Fragment shader 46, sometimes referred to as a pixel shader, may bea shader program that executes on shader processor 22. For example, thesource code for fragment shader 46 may be stored in system memory 26,and compiler 18 may compile the source code of fragment shader 46 togenerate the object code of fragment shader 46. Alternatively, systemmemory 26 may store the object code for fragment shader 46 without itnecessarily being generated by compiler 18.

Fragment shader 46 may output the color values for each of the pixels onthe display. For example, fragment shader 46 may define the color ofeach pixel based on a red-green-blue (RGB) component. Fragment shader 46may utilize 8-bits to define the red component, 8-bits to define thegreen component, and 8-bits to define the blue component, as oneillustrative example. Fragment shader 46 may output the color values toper-fragment operation unit 50.

Per-fragment operation unit 50 may cull pixels that are not viewable.For example, a pixel of a further away object may be overlapped by apixel of a closer object, which per-fragment operation unit 50 maydetermine from a z-buffer. The overlapping may cause the pixel of thefurther away object to be fully occluded. In this case, per-fragmentoperation unit 50 may cull the overlapped pixel. Per-fragment operationunit 50 may also blend pixels together. For example, an overlappingpixel may be translucent so that it does not fully occlude theoverlapped pixel. In this case, per-fragment operation unit 50 may blendthe color of these pixels together.

The output of per-fragment operation unit 50 may be pixel values (e.g.,color) for the pixels on the display. Per-fragment operation unit 50 mayoutput the pixel values to frame buffer 52, of system memory 26, fortemporary storage. Once frame buffer 52 is full, frame buffer 52 maystore the pixel values for each of the pixels on the display.

Frame buffer 52 may be considered as a 2D array of storage locations.The number of storage locations with frame buffer 52 may be at leastequal to the number of pixels of a display. Also, the storage locationswithin frame buffer 52 may correspond to a location on the display. Forexample, the top-left storage location within frame buffer 52 maycorrespond to the top-left pixel of the display, the storage location tothe right of the top-left storage location within frame buffer 52 maycorrespond to the pixel to the right of the top-left pixel of thedisplay, and so forth.

After the completion of the first glDraw command, the storage locationslocated in the left half of frame buffer 52 may store the pixel valuesfor the left-eye image because the left half of frame buffer 52 maycorrespond to the left-half of the display. Similarly, after thecompletion of the second glDraw command, the storage locations locatedin the right half of frame buffer 52 may store the pixel values for theright-eye image because the right half of frame buffer 52 may correspondto the right half of the display. Therefore, after completion of thefirst and second glDraw commands, frame buffer 52 may store the pixelvalues for the left-eye image and the pixel values for the right-eyeimage.

FIG. 3 is a block diagram illustrating the example device of FIG. 1 infurther detail. For instance, FIG. 3 illustrates device 10 of FIG. 1 infurther detail. For example, as indicated above, examples of device 10include, but are not limited to, mobile wireless telephones, PDAs, videogaming consoles that include video displays, mobile video conferencingunits, laptop computers, desktop computers, television set-top boxes,and the like.

As illustrated in FIG. 3, device 10 may include application processor12, GPU 20, system memory 26, which includes frame buffer 52,transceiver module 56, user interface 58, display 60, and displayprocessor 62. Application processor 12, GPU, and system memory 26 may besubstantially similar or identical to application processor 12, GPU 20,and system memory 26 of FIGS. 1 and 2. For purposes of brevity, only thecomponents that are shown in FIG. 3, but not shown in FIGS. 1 and 2 aredescribed in detail.

Device 10, as illustrated in FIG. 3, may include additional modules orunits not shown in FIG. 3 for purposes of clarity. For example, device10 may include a speaker and a microphone, neither of which are shown inFIG. 3, to effectuate telephonic communications in examples where device10 is a mobile wireless telephone, or a speaker where device 10 is amedia player. Furthermore, the various modules and units shown in device10 may not be necessary in every example of device 10. For example, userinterface 58 and display 60 may be external to device 10 in exampleswhere device 10 is a desktop computer or other device that is equippedto interface with an external user interface or display.

Examples of user interface 58 include, but are not limited to, atrackball, a mouse, a keyboard, and other types of input devices. Userinterface 58 may also be a touch screen and may be incorporated as apart of display 60. Transceiver module 56 may include circuitry to allowwireless or wired communication between device 10 and another device ora network. Transceiver module 56 may include one or more modulators,demodulators, amplifiers, antennas and other such circuitry for wired orwireless communication. Display 60 may comprise a liquid crystal display(LCD), an organic light emitting diode display (OLED), a cathode raytube (CRT) display, a plasma display, a polarized display, or anothertype of display device.

Display processor 62 may be configured to cause display 60 to displaystereoscopic view. There may be various techniques that displayprocessor 62 may utilize to cause display 60 to display stereoscopicview, and aspects of this disclosure may utilize any of thesetechniques. For example, display processor 62 may retrieve the left-eyeimage from the left half of frame buffer 52, retrieve the right eyeimage from the right-half of frame buffer 52, and interleave the twoimages together to provide the stereoscopic view.

As another example, display processor 62 may control the refresh rate ofdisplay 60. In this example, during each refresh cycle, displayprocessor 62 may cycle between the left-eye image and the right-eyeimage. For instance, display processor 62 may retrieve the left-eyeimage from the left half of frame buffer 52, expand the left-eye imageto the entirety of display 60, and display left-eye image on display 60for one refresh cycle. Then, for the next refresh cycle, displayprocessor 62 may perform substantially similar functions, but for theright-eye image stored in the right half of frame buffer 52. In otherwords, display 60 may display the left-eye image, then the right-eyeimage, then the left-eye image, and so forth.

The viewer may be wearing specialized glasses that are synchronized withthe refresh rate of display processor 62. For example, while display 60is displaying the left-eye image, the specialized glasses may shutterclose the right lens so that only the left eye of the viewer capturesthe left-eye image. Then, while display 60 is displaying the right-eyeimage, the specialized glasses may shutter close the left lens so thatonly the right eye of the viewer captures the right-eye image, and soforth. If the refresh rate is fast enough, the viewer perceivesstereoscopic view where the image pops out of or pushes into display 60and encompasses a 3D volume.

In some examples, some conventional display processors may notconfigured to cause display 60 to display stereoscopic view. In theseexamples, the viewer may couple device 10 to a display that includes adisplay processor, such as display processor 62, which is configured tocause the display to present the stereoscopic view. For example, theviewer may couple device 10 to a stereoscopic view enabled televisionvia transceiver module 56. For instance, the viewer may coupletransceiver module 56 to the television via a high-definition multimediainterface (HDMI) wire. In this example, application processor 12 or GPU20 may instruct transceiver module 56 to transmit the pixel valuesstored in frame buffer 52 to the display processor of the television.The display processor of this television may then cause the televisionto display the left-eye and right-eye images to form the stereoscopicview.

In these examples, it may still be possible for the display of device 10to display the left-eye and right-eye images. However, because displayprocessor 62 of device 10 may not be able to cause display 60 of device10 to present the stereoscopic view, in this example, display 60 maydisplay the left-eye image and the right-eye image side-by-side. Forexample, the left-half of display 60 may display the left-eye image, andthe right-half of display 60 may display the right-eye image. This maybe because of the viewport transformation described above. In this case,even with specialized glasses, the viewer may not experience thestereoscopic view simply by viewing display 60, but would experiencestereoscopic view by viewing the stereoscopic view enabled television.

FIG. 4 is a flowchart illustrating an example operation in accordancewith one or more example techniques described in this disclosure. Forpurposes of illustration, reference is made to FIGS. 1 and 2.

A processor may receive instructions for a vertex shader that isdesigned to generate an image of a mono view and that is to be executedon a shader processor of a graphics processing unit (GPU) (64). Forexample, application processor 12, via the execution of graphics driverwrapper 16, may receive instructions for vertex shader 28. As describedabove, vertex shader 28 may designed to generate graphics content for amono view, and may be designed to be executed on shader processor 22 ofGPU 20.

The processor may modify the instructions of the vertex shader toinclude one or more instruction that cause the vertex shader, whenexecuted on the shader processor of the GPU, to generate graphicscontent for a first image of a stereoscopic view after a first executionof the vertex shader and graphics content for a second image of thestereoscopic view after a second execution of the vertex shader of astereoscopic view (66). The first image may be the left-eye image andthe second image may be the right-eye image.

For example, graphics driver wrapper 16 may receive the source code ofvertex shader 28, and may include the gl_Position.x+=X command into thesource code of vertex shader 28. Compiler 18 may compile the modifiedsource code of vertex shader 28 to generate the object coded of modifiedvertex shader 30. Graphics driver wrapper 16 may cause shader processor22 to execute the object code of modified vertex shader 30, and mayprovide shader processor 22 with the value of +D for X. After graphicsdriver wrapper 16 issues a first glDraw command, graphics driver wrapper16 may cause shader processor 22 to again execute the object code ofmodified vertex shader 30, and may provide shader processor 22 with thevalue of −D for X.

A processor may modify a command that defines a viewport for the imageof the mono view to a first command, for a fixed-function unit of theGPU that is different from the shader processor, that defines a viewportfor the first image, and a second command, for the fixed-function unitof the GPU, that defines a viewport for the second image (68). In thisexample, the fixed-function unit may be the viewport transformation unit42 of FIG. 2. As illustrated, and described above, viewporttransformation unit 42 is different from shader processor 22.

As one example, graphics driver wrapper 16 may modify the glViewport (0,0, width, length) command, which was previously issued by application32, to glViewport (0, 0, width/2, length) command for rendering theleft-eye image, and for rendering the right-eye image, graphics driverwrapper 16 may modify the glViewport (0, 0, width, length) command toglViewport (width/2, 0, width/2, length) command. In some examples,graphics driver wrapper 16 may shift or shift and stretch the viewportsfor the first and second images, as discussed above. In some examples,graphics driver wrapper 16 may shift or shift and stretch the viewportfor the first and second images, while modifying the instruction thatdefines the viewport for the mono view, to define the viewports for thefirst and second images.

The following pseudo-code provides an example of the functionality ofgraphics driver wrapper 16 and application 32. This pseudo-code is meantto assist with understanding and should not be considered limiting.

-   -   1. Graphic driver wrapper 16 intercepts glShaderSource command        issued by application 32 to intercept the source code of vertex        shader 28.    -   2. Graphics driver wrapper 16 inserts “uniform float X” into the        instructions of vertex shader 28, where “uniform” is a user        defined standard attribute variable in OpenGL and OpenGL ES,        with programmable shaders.    -   3. Graphics driver wrapper 16 inserts “gl_Position.x+=X” command        in the source code of vertex shader 28.    -   4. Application 32 executes glCompileShader command that causes        compiler 18 to compile the modified source code instructions of        vertex shader 28 to generate the object code of modified vertex        shader 30.    -   5. Application 32 executes the following commands to link to the        object code of modified vertex shader 30:        -   programObject=glCreateProgram( )        -   glAttachShader(programObject, vertexShader);        -   glAttachShader(programObject, fragmentShader);        -   glLinkProgram(programObject)    -   6. Graphics driver wrapper 16 intercepts glDraw commands (e.g.,        glDrawArrays and glDrawElements) when called by application 32,        and blocks the commands from being transmitted to GPU 20.    -   7. Graphics driver wrapper 16 issues the following commands:        -   glGetInteger(GL_CURRENT_PROGRAM, &program); //to get pointer            to the current vertex shader        -   Modify the glViewport command to generate viewport for            left-eye image as described above.        -   p=glGetUniformLocation(program, X); to get the pointer to            uniform X        -   glUniform1f(p,D); //to set the value of X equal to D.        -   glDraw command //to cause GPU 20 to generate the graphics            content for the left-eye image    -   8. Repeat the steps following from 7, with the following        modifications to generate the graphics content for the right-eye        image:        -   Modify the glViewport command to generate the viewport for            the right-eye image as described above.        -   glUniform1f(p, −D) //to set the value of X equal to −D.        -   glDraw command //to cause GPU 20 to generate the graphics            content for the right-eye image.

In one or more examples, the functions described may be implemented inhardware, software, firmware, or any combination thereof. If implementedin software, the functions may be stored as one or more instructions orcode on a computer-readable medium. Computer-readable media may includecomputer data storage media. Data storage media may be any availablemedia that can be accessed by one or more computers or one or moreprocessors to retrieve instructions, code and/or data structures forimplementation of the techniques described in this disclosure. By way ofexample, and not limitation, such computer-readable media can compriserandom access memory (RAM), read-only memory (ROM), EEPROM, CD-ROM orother optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium that can be used to store desiredprogram code in the form of instructions or data structures and that canbe accessed by a computer. Disk and disc, as used herein, includescompact disc (CD), laser disc, optical disc, digital versatile disc(DVD), floppy disk and Blu-ray disc where disks usually reproduce datamagnetically, while discs reproduce data optically with lasers.Combinations of the above should also be included within the scope ofcomputer-readable media.

The code may be executed by one or more processors, such as one or moredigital signal processors (DSPs), general purpose microprocessors,application specific integrated circuits (ASICs), field programmablelogic arrays (FPGAs), or other equivalent integrated or discrete logiccircuitry. Accordingly, the term “processor,” as used herein may referto any of the foregoing structure or any other structure suitable forimplementation of the techniques described herein. Also, the techniquescould be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide varietyof devices or apparatuses, including a wireless handset, an integratedcircuit (IC) or a set of ICs (i.e., a chip set). Various components,modules or units are described in this disclosure to emphasizefunctional aspects of devices configured to perform the disclosedtechniques, but do not necessarily require realization by differenthardware units. Rather, as described above, various units may becombined in a hardware unit or provided by a collection ofinteroperative hardware units, including one or more processors asdescribed above, in conjunction with suitable software and/or firmware.

Various examples have been described. These and other examples arewithin the scope of the following claims.

1. A method comprising: receiving, with a processor, instructions for avertex shader that is configured to generate an image of a mono view andthat is to be executed on a shader processor of a graphics processingunit (GPU); modifying, with the processor, the instructions of thevertex shader to include one or more instructions that cause the vertexshader, when executed on the shader processor of the GPU, to generategraphics content for a first image of a stereoscopic view after a firstexecution of the vertex shader, and graphics content for a second imageof the stereoscopic view after a second execution of the vertex shader;and modifying, with the processor, a command that defines a viewport forthe image of the mono view to a first command, for a fixed-function unitof the GPU that is different from the shader processor, that defines aviewport for the first image, and a second command, for thefixed-function unit of the GPU, that defines a viewport for the secondimage.
 2. The method of claim 1, further comprising: executing, with theshader processor of the GPU, object code of the modified instructions ofthe vertex shader; and executing, with the fixed-function unit of theGPU, the first command that defines the viewport for the first image,and the second command that defines the viewport for the second image.3. The method of claim 1, wherein modifying the command that defines theviewport for the image such that the first command is configured toconstrain the first image to a first portion of a display, and thesecond command is configured to constrain the second image to a secondportion of the display.
 4. The method of claim 1, wherein modifying thecommand that defines the viewport for the image further comprisesshifting or shifting and stretching the viewport for the first image,and shifting or shifting and stretching the viewport for the secondimage.
 5. The method of claim 1, wherein modifying the command thatdefines the viewport for the image comprises modifying a glViewport (0,0, width, length) command to the first command that comprises aglViewport (0, 0, width/2, length) command, and the second command thatcomprises a glViewport (width/2, 0, width/2, length) command, andwherein width equals a width of a display, and length equals a length ofthe display.
 6. The method of claim 1, wherein modifying the commandthat defines the viewport for the image comprises modifying a glViewport(0, 0, width, length) command to the first command that comprises aglViewport (0−Vps, 0, width/2, length) command or a glViewport (0−Vps,0, width/2+Vps, length) command, and the second command that comprises aglViewport (width/2+Vps, 0, width/2, length) command or a glViewport(width/2, 0, width/2+Vps, length) command, and wherein width equals awidth of a display, length equals a length of the display, and Vpsdefines an amount by which the stereoscopic view pops out of or pushesinto the display.
 7. The method of claim 1, wherein the fixed-functionunit comprises a viewport transformation unit of a fixed-functionpipeline of the GPU.
 8. The method of claim 1, wherein receivinginstructions of the vertex shader comprises receiving, with a graphicsdriver wrapper executing on the processor, the instructions of thevertex shader, wherein modifying the instructions of the vertex shadercomprises modifying, with the graphics driver wrapper executing on theprocessor, the instructions of the vertex shader, and wherein modifyingthe command that defines the viewport comprises modifying, with thegraphics driver wrapper executing on the processor, the command thatdefines the viewport.
 9. The method of claim 1, wherein modifying theinstructions of the vertex shader comprises adding an instruction intothe vertex shader that modifies at least one clipping coordinate for theimage of the mono view.
 10. The method of claim 9, wherein adding theinstruction into the vertex shader that modifies at least one clippingcoordinate comprises adding an instruction into the vertex shader thatupdates a variable that stores the at least one clipping coordinate. 11.The method of claim 10, wherein adding the instruction into the vertexshader that updates the variable that stores the at least one clippingcoordinate comprises adding an instruction for adding a constant valueto the at least one clipping coordinate in the first execution, andadding an instruction for subtracting the constant value from the atleast one clipping coordinate in the second execution.
 12. The method ofclaim 10, wherein adding the instruction into the vertex shader thatmodifies the at least one clipping coordinate for the image of the monoview comprises adding a gl.Position.x+=X command, wherein X equals +D inthe first execution, and −D in the second execution, and wherein Dequals an estimation of half a distance between a left eye and a righteye of a viewer.
 13. The method of claim 1, wherein modifying theinstructions of the vertex shader to include one or more instructionscomprises only adding an instruction into the vertex shader thatmodifies one clipping coordinate for the image of the mono view.
 14. Anapparatus comprising: a graphics processing unit (GPU) that includes ashader processor and a fixed-function unit, different from the shaderprocessor, of a fixed-function pipeline; and a processor operable to:receive instructions for a vertex shader that is configured to generatean image of a mono view and that is to be executed on the shaderprocessor of the GPU; modify the instructions of the vertex shader toinclude one or more instructions that cause the vertex shader, whenexecuted on the shader processor of the GPU, to generate graphicscontent for a first image of a stereoscopic view after a first executionof the vertex shader, and graphics content for a second image of thestereoscopic view after a second execution of the vertex shader; andmodify a command that defines a viewport for the image of the mono viewto a first command, for the fixed-function unit of the GPU that isdifferent from the shader processor, that defines a viewport for thefirst image, and a second command, for the fixed-function unit of theGPU, that defines a viewport for the second image.
 15. The apparatus ofclaim 14, wherein the shader processor of the GPU is configured toexecute object code of the modified instructions of the vertex shader,and wherein the fixed-function unit of the GPU is configured to executethe first command that defines the viewport for the first image, and thesecond command that defines the viewport for the second image.
 16. Theapparatus of claim 14, wherein the processor is operable to modify thecommand that defines the viewport for the image such that the firstcommand is configured to constrain the first image to a first portion ofa display, and the second command is configured to constrain the secondimage to a second portion of the display.
 17. The apparatus of claim 14,wherein the processor is further operable to modify the command thatdefines the viewport for the image to shift or shift and stretch theviewport for the first image, and shift or shift and stretch theviewport for the second image.
 18. The apparatus of claim 14, wherein,to modify the command that defines the viewport for the image, theprocessor is operable to modify a glViewport (0, 0, width, length)command to the first command that comprises a glViewport (0, 0, width/2,length) command, and the second command that comprises a glViewport(width/2, 0, width/2, length) command, and wherein width equals a widthof a display, and length equals a length of the display.
 19. Theapparatus of claim 14, wherein, to modify the command that defines theviewport for the image, the processor is operable to modify a glViewport(0, 0, width, length) command to the first command that comprises aglViewport (0−Vps, 0, width/2, length) command or a glViewport (0−Vps,0, width/2+Vps, length) command, and the second command that comprises aglViewport (width/2+Vps, 0, width/2, length) command or a glViewport(width/2, 0, width/2+Vps, length) command, and wherein width equals awidth of a display, length equals a length of the display, and Vpsdefines an amount by which the stereoscopic view pops out of thedisplay.
 20. The apparatus of claim 14, wherein the fixed-function unitcomprises a viewport transformation unit.
 21. The apparatus of claim 14,wherein the processor is operable to execute a graphics driver wrapperto receive instructions for a vertex shader, modify the instructions ofthe vertex shader, and modify the command that defines a viewport forthe image.
 22. The apparatus of claim 14, wherein, to modify theinstructions of the vertex shader, the processor is operable to add aninstruction into the vertex shader that modifies at least one clippingcoordinate for the image of the mono view.
 23. The apparatus of claim22, wherein, to add the instruction into the vertex shader that modifiesat least one clipping coordinate, the processor is operable to add aninstruction into the vertex shader that updates a variable that storesthe at least one clipping coordinate.
 24. The apparatus of claim 23,wherein, to add the instruction into the vertex shader that updates thevariable that stores the at least one clipping coordinate, the processoris operable to add an instruction for adding a constant value to the atleast one clipping coordinate in the first execution, and add aninstruction for subtracting the constant value from the at least oneclipping coordinate in the second execution.
 25. The apparatus of claim23, wherein, to add the instruction into the vertex shader that modifiesthe at least one clipping coordinate for the image of the mono view, theprocessor is operable to add a gl.Position.x+=X command, wherein Xequals +D in the first execution, and −D in the second execution, andwherein D equals an estimation of half a distance between a left eye anda right eye of a viewer.
 26. The apparatus of claim 14, wherein, tomodify the instructions of the vertex shader to include one or moreinstructions, the processor is operable to only add an instruction intothe vertex shader that modifies one clipping coordinate for the image ofthe mono view.
 27. An apparatus comprising: a graphics processing unit(GPU) that includes a shader processor and a fixed-function unit,different from the shader processor, of a fixed-function pipeline; and aprocessor that includes: means for receiving instructions for a vertexshader that is configured to generate an image of a mono view and thatis to be executed on the shader processor of the GPU; means formodifying the instructions of the vertex shader to include one or moreinstructions that cause the vertex shader, when executed on the shaderprocessor of the GPU, to generate graphics content for a first image ofa stereoscopic view after a first execution of the vertex shader, andgraphics content for a second image of the stereoscopic view after asecond execution of the vertex shader; and means for modifying a commandthat defines a viewport for the image of the mono view to a firstcommand, for a fixed-function unit of the GPU that is different from theshader processor, that defines a viewport for the first image, and asecond command, for the fixed-function unit of the GPU, that defines aviewport for the second image.
 28. The apparatus of claim 27, whereinthe shader processor of the GPU is configured to execute object code ofthe modified instructions of the vertex shader, and wherein thefixed-function unit of the GPU is configured to execute the firstcommand that defines the viewport for the first image, and the secondcommand that defines the viewport for the second image.
 29. Theapparatus of claim 27, wherein the means for modifying the command thatdefines the viewport for the image such that the first command isconfigured to constrain the first image to a first portion of a display,and the second command is configured to constrain the second image to asecond portion of the display.
 30. The apparatus of claim 27, whereinthe means for modifying the command that defines the viewport for theimage further comprises means for shifting or shifting and stretchingthe viewport for the first image, and means for shifting or shifting andstretching the viewport for the second image.
 31. The apparatus of claim27, wherein the means for modifying the instructions of the vertexshader comprises means for adding an instruction into the vertex shaderthat modifies at least one clipping coordinate for the image of the monoview.
 32. The apparatus of claim 27, wherein the means for modifying theinstructions of the vertex shader to include one or more instructionscomprises means for only adding an instruction into the vertex shaderthat modifies one clipping coordinate for the image of the mono view.33. A non-transitory computer-readable storage medium comprisinginstructions that, when executed, cause one or more processors to:receive instructions for a vertex shader that is designed to generate animage of a mono view and that is to be executed on a shader processor ofa graphics processing unit (GPU); modify the instructions of the vertexshader to include one or more instructions that cause the vertex shader,when executed on the shader processor of the GPU, to generate graphicscontent for a first image of a stereoscopic view after a first executionof the vertex shader, and graphics content for a second image of thestereoscopic view after a second execution of the vertex shader; andmodify a command that defines a viewport for the image of the mono viewto a first command, for a fixed-function unit of the GPU that isdifferent from the shader processor, that defines a viewport for thefirst image, and a second command, for the fixed-function unit of theGPU, that defines a viewport for the second image.
 34. Thenon-transitory computer-readable storage medium of claim 33, furthercomprising instructions to: execute, with the shader processor of theGPU, object code of the modified instructions of the vertex shader; andexecute, with the fixed-function unit of the GPU, the first command thatdefines the viewport for the first image, and the second command thatdefines the viewport for the second image.
 35. The non-transitorycomputer-readable storage medium of claim 33, wherein the instructionsto modify the command that defines the viewport for the image compriseinstructions to modify the command that defines the viewport for theimage of the mono view to the first command that constrains the firstimage to a first portion of a display, and the second command thatconstrains the second image to a second portion of the display.
 36. Thenon-transitory computer-readable storage medium of claim 33, wherein theinstructions to modify the command that defines the viewport for theimage further comprises instructions to shift or shift and stretch theviewport for the first image, and shift or shift and stretch theviewport for the second image.
 37. The non-transitory computer-readablestorage medium of claim 33, wherein the instructions to modify theinstructions of the vertex shader comprise instructions to add aninstruction into the vertex shader that modifies at least one clippingcoordinate for the image of the mono view.
 38. The non-transitorycomputer-readable storage medium of claim 33, wherein the instructionsto modify the instructions of the vertex shader to include one or moreinstructions comprises instructions to only add an instruction into thevertex shader that modifies one clipping coordinate for the image of themono view.